On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
wrote:
> And I don't agree that the project would be better off with something
> else, if it was, somebody would have proposed an alternative by now,
> but there aren't any. I have tried gitg, and giggle, and I have even
> contributed to them, but
Felipe Contreras :
> > The main objective of the logfile design is to make hand-crafting
> > these easy.
>
> Here's another version with YAML:
Clever.
Now I have to decide if I should allow my aesthetic dislike of YAML to
prevail despite the fact that it's pretty well suited to this job. Ther
[url=http://www.cheaptiffanyjewellerysale.co.uk/]tiffany uk[/url] is
certainly maintaining that will available your different singapore jewelry
generates near to the universe so that the human beings with countless many
section benefit your preferred specialist together with lesser tiffany
jewel
Felipe Contreras :
> I believe that log file is much more human readable. Yet I still fail
> to see why would anybody want so much detail only to import tarballs.
The first time I needed such a tool (and I really should have built it then)
was during the events I wrote up in 2010 the INTERCAL Rec
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond wrote:
> ---
> commit 1
> directory foo-1.1
>
> Release 1.1 of project foo
> .
> commit 2
> directory foo-1.2
>
> ..This is an example of a byte-stuffed line.
>
> Release 1.2 of project foo
> .
> commit 3
> director
On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
wrote:
> I'm finding the behavior of `git difftool -d` surprising. It seems that it
> only uses symlinks to the working copy for files that are modified in the
> working copy since the most recent commit. I would have expected it to use
> symlinks for
Junio C Hamano wrote:
> "Olsen, Alan R" writes:
> > I found an interesting bug in git-format-patch.
> >
> > Say you have a branch A. You create branch B and add a patch to
> > it. You then merge that patch into branch A. After the merge,
> > some other process (we will call it 'gerrit') uses ann
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano wrote:
> Chris Rorvick writes:
>
>> diff --git a/remote.c b/remote.c
>> index 4a6f822..012b52f 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref
>> *remote_refs, int send_mirror,
>>
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano wrote:
> Chris Rorvick writes:
>
>> Pushes must already (by default) update to a commit-ish due the fast-
>> forward check in set_ref_status_for_push(). But rejecting for not being
>> a fast-forward suggests the situation can be resolved with a me
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano wrote:
> Chris Rorvick writes:
>
>> Pass all rejection reasons back from transport_push(). The logic is
>> simpler and more flexible with regard to providing useful feedback.
>>
>> Signed-off-by: Chris Rorvick
>> ---
>
> In any case, naming it as
On 11/26/2012 5:30 PM, Junio C Hamano wrote:
Brandon Casey writes:
From: Brandon Casey
This example in the documentation seems to be trying to describe the likely
remote tracking branch that will be updated by a push to the "origin" remote
with the destination branch 'satellite/master', but
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed changes
Brandon Casey writes:
> From: Brandon Casey
>
> This example in the documentation seems to be trying to describe the likely
> remote tracking branch that will be updated by a push to the "origin" remote
> with the destination branch 'satellite/master', but it forgot to specify
> the remote name
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Might be easier to just call 'git ls-files --with-three foo', but I
>> don't see the point of those calls:
>
> Ah, much is now explained. You were looking at an old version. I had
> in fact already fixed the subdire
From: Brandon Casey
This example in the documentation seems to be trying to describe the likely
remote tracking branch that will be updated by a push to the "origin" remote
with the destination branch 'satellite/master', but it forgot to specify
the remote name in the path specification.
So,
Felipe Contreras writes:
> On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> I'm rerolling this series with the changes fron Junio, plus a bit more
>>> cleanups.
>>>
>>> I dropped the last patch, because I found an issue and a separate patch
>>> series
Krzysztof Mazur writes:
> On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur writes:
>>
>> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
>> >> sloppy, even though it is not *too* bad. Also do we know this
>> >
>> > ok, I will fix that.
>>
Felipe Contreras :
> Might be easier to just call 'git ls-files --with-three foo', but I
> don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
in fact already fixed the subdirectories bug (I've updated my
regression test to check) and have ful
On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> >> sloppy, even though it is not *too* bad. Also do we know this
> >
> > ok, I will fix that.
> >
> >> function will never be used
Alexandre Julliard writes:
> Junio C Hamano writes:
>
>> Enrico Scholz writes:
>>
>>> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
>>> git, the command fails with
>>>
>>> | ... is not a git working tree
>>>
>>> This is caused by creating submodules with '--separate-g
At 09:58 -0800 26 Nov 2012, Junio C Hamano wrote:
Kacper Kornet writes:
The change of order of parents happens at the very last moment, so
"ours" in merge options is local version and "theirs" upstream.
That may be something that wants to go to the proposed commit log
message. I am neutral
On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> I'm rerolling this series with the changes fron Junio, plus a bit more
>> cleanups.
>>
>> I dropped the last patch, because I found an issue and a separate patch
>> series
>> would take care of that. Other t
On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> 1) I tried it, and it doesn't seem to import (pack?) are repository
>> with sub-directories in it
>
> I'll make sure my regression test checks this case. The options to git
> ls-files are a bit confusing and it's pos
Felipe Contreras writes:
> I'm rerolling this series with the changes fron Junio, plus a bit more
> cleanups.
>
> I dropped the last patch, because I found an issue and a separate patch series
> would take care of that. Other than that the main changes remain the same.
>
> The old remote-testgit
Krzysztof Mazur writes:
>> Not having this new code inside "elsif (/^e/) { }" feels somewhat
>> sloppy, even though it is not *too* bad. Also do we know this
>
> ok, I will fix that.
>
>> function will never be used for addresses other than recipients' (I
>> gave a cursory look to see what is do
Hi,
[Thorsten Glaser , 2012-11-25 17:27]:
> On a multi-core machine, the garbage collection of git, as well
> as pack compression on the server side when someone clones a
> repository remotely, the compression is normally done automatically
> using multiple threads of execution.
>
> That may be f
"Olsen, Alan R" writes:
> I found an interesting bug in git-format-patch.
>
> Say you have a branch A. You create branch B and add a patch to
> it. You then merge that patch into branch A. After the merge, some
> other process (we will call it 'gerrit') uses annotate and changes
> the comment on
Sverre Rabbelier writes:
> On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
> wrote:
>>> We added rev_cmdline_info since then so that we can tell what refs
>>> were given from the command line in what way, and I thought that we
>>> applied a patch from Sverre that uses it instead of the obj
Junio C Hamano :
> Even though "={n} title ={n}" is a valid AsciiDoc heading, all other
> files use (older) underscored titles; please refrain from being
> original.
>
> Especially, this interferes with the way the api-index.txt file in
> the same directory is autogenerated.
Noted for the future,
Felipe Contreras :
> 1) I tried it, and it doesn't seem to import (pack?) are repository
> with sub-directories in it
I'll make sure my regression test checks this case. The options to git
ls-files are a bit confusing and it's possible my invocation of it
needs to change.
> 2) Using 'git fast-
Brandon Casey writes:
> So, this series should result in s-o-b and "(cherry picked from...)" being
> appended to commit messages in a more consistent and deterministic way. For
> example, the decision about whether to insert a blank line before appending
> a s-o-b. As discussed, cherry-pick and
On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
wrote:
>> We added rev_cmdline_info since then so that we can tell what refs
>> were given from the command line in what way, and I thought that we
>> applied a patch from Sverre that uses it instead of the object
>> flags. Am I misremembering
e...@thyrsus.com (Eric S. Raymond) writes:
> @@ -0,0 +1,91 @@
> += Integrating new subcommands =
> +
> +This is how-to documentation for people who want to add extension
> +commands to git. It should be read alongside api-builtin.txt.
> +
> +== Runtime environment ==
> +
> +git subcommands are st
Junio C Hamano :
> I'll reword the title (readers of "git log" output 6 months down the
> road will not care if this is the third try or the first one) and
> tweak things here and there before queuing.
Result looks good from here.
The next things on my git to-do list are
1. Audit the in-tree P
I found an interesting bug in git-format-patch.
Say you have a branch A. You create branch B and add a patch to it. You then
merge that patch into branch A. After the merge, some other process (we will
call it 'gerrit') uses annotate and changes the comment on the patch that
exists on branch B
- Original Message -
> From: "Jason J CTR Pyeron (US)"
> Sent: Monday, November 26, 2012 4:06:59 PM
> Subject: RE: git bundle format [OT]
>
> > First, a shot out of left field: how about a patch based workflow?
> > (similar to the mailing list, just replace email with sneakernet)
> > Patc
Thanks.
--
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
Hi Junio,
On Mon, 26 Nov 2012, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > If you changed your stance on the patch Sverre and I sent to fix this,
> > we could get a non-partial fix for this.
>
> This is long time ago so I may be misremembering the details, but I
> thought the ori
> -Original Message-
> From: Stephen Bash
> Sent: Monday, November 26, 2012 3:56 PM
>
> - Original Message -
> > From: "Jason J CTR Pyeron (US)"
> > Sent: Monday, November 26, 2012 2:24:54 PM
> > Subject: git bundle format
> >
> > I am facing a situation where I would like to use
From: "W. Trevor King"
This allows users to checkout the current
superproject-recorded-submodule-sha as a branch, avoiding the detached
head state that the standard submodule update creates. This may be
useful for the existing --rebase/--merge workflows which already avoid
detached heads.
It is
From: "W. Trevor King"
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 28eb4b1..f4a681c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -640,7 +640,7 @@ Maybe you want to use 'update --init'?")"
From: "W. Trevor King"
On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> We could add
>
> $ git submodule update --branch
>
> to checkout the gitlinked SHA1 as submodule..branch in each of
> the submodules, leaving the submodules on the .gitmodules-configured
> branch. Effectiv
From: "W. Trevor King"
This allows users to override the .gitmodules value with a
per-repository value.
Signed-off-by: W. Trevor King
---
Documentation/config.txt | 9 +
git-submodule.sh | 7 +++
t/t7400-submodule-basic.sh | 18 ++
3 files changed, 30
From: "W. Trevor King"
This option allows you to record a submodule..branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current cons
- Original Message -
> From: "Jason J CTR Pyeron (US)"
> Sent: Monday, November 26, 2012 2:24:54 PM
> Subject: git bundle format
>
> I am facing a situation where I would like to use git bundle but at
> the same time inspect the contents to prevent a spillage[1].
As someone who faced a s
On Mon, Nov 26, 2012 at 9:50 PM, Pyeron, Jason J CTR (US)
wrote:
>> -Original Message-
>> From: Felipe Contreras
>> Sent: Monday, November 26, 2012 3:20 PM
>>
>> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
>> wrote:
>> > I may need to be nudged in a better direction, but ple
Peter Oberndorfer writes:
> Does anybody have a idea which git command would output the diff
> of a untracked file against /dev/null?
The "--no-index" option is meant as a bolt-on to let you use various
features of "git diff" that is missing from other people's "diff" in
a context where git does
> -Original Message-
> From: Junio C Hamano
> Sent: Monday, November 26, 2012 3:38 PM
>
> "Pyeron, Jason J CTR (US)" writes:
>
> > In this situation we should assume that the bundle does not have
> > any content which is already in the public repository, that is it
> > has the minimum dat
> -Original Message-
> From: Felipe Contreras
> Sent: Monday, November 26, 2012 3:20 PM
>
> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
> wrote:
> > I may need to be nudged in a better direction, but please try to
> understand my intentions.
> >
> > I am facing a situation w
Antoine Pelisse writes:
>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in the history so nobody will ref
On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse wrote:
>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in
"Pyeron, Jason J CTR (US)" writes:
> In this situation we should assume that the bundle does not have
> any content which is already in the public repository, that is it
> has the minimum data to make it pass a git bundle verify from the
> public repositories point of view. We would then take the
On 2012-10-08 18:44, Peter Oberndorfer wrote:
> Hi,
>
> is there a way to tell git diff about lines that are uninteresting?
> I mean lines which do not contain a lot of information and
> appear several times in pre and post image.
>
> For example whitespace or language dependent stuff like.
> {
> }
On 2012-10-24 20:33, Peter Oberndorfer wrote:
> Hi,
>
> i am using a textconv filter to display .doc files as plain text.
> It seems git gui does not use this textconv filter for displaying new
> unstaged files
> (other files? = _O)
> It seems diff.tcl start_show_diff calls show_other_diff because
On Thu, Nov 15, 2012 at 10:28 PM, Eric S. Raymond wrote:
> Some days ago I reported that I was attempting to write a tool that could
> (a) take a git repo and unpack it into a tarball sequence plus a metadata log,
> (b) reverse that operation, packing a tarball and log sequence into a repo.
>
> Th
> I am not sure I follow the above, but anyway, I think the patch does
> is safe because (1) future "fast-export" will not refer to these
> pruned objects in its output (we have decided that these pruned
> objects are not used anywhere in the history so nobody will refer to
> them) and (2) we still
e...@thyrsus.com (Eric S. Raymond) writes:
> This document contains no new policies or proposals; it attempts
> to document established practices and interface requirements.
>
> Signed-off-by: Eric S. Raymond
I'll reword the title (readers of "git log" output 6 months down the
road will not care
Felipe Contreras writes:
> 3) Full name + fqdm
>
> Who should the emails appear to be from?
> [Felipe Contreras ]
> ...
> This is bad, because we will try with an address such as
> 'feli...@nysa.felipec.org', which is most likely not what the user
> wants, but the user will get warned by defa
Left off a citation to an old thread.
> -Original Message-
> From: Pyeron, Jason J CTR (US)
> Sent: Monday, November 26, 2012 2:25 PM
>
> I may need to be nudged in a better direction, but please try to
> understand my intentions.
>
> I am facing a situation where I would like to use git
I may need to be nudged in a better direction, but please try to understand my
intentions.
I am facing a situation where I would like to use git bundle but at the same
time inspect the contents to prevent a spillage[1].
Given we have a public repository which was cloned on to a secret developme
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse
---
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..9374
Chris Rorvick writes:
> diff --git a/remote.c b/remote.c
> index 4a6f822..012b52f 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs,
> int send_mirror,
>*
>* (1) if the old thing does not exist,
Chris Rorvick writes:
> Pushes must already (by default) update to a commit-ish due the fast-
> forward check in set_ref_status_for_push(). But rejecting for not being
> a fast-forward suggests the situation can be resolved with a merge.
> Flag these updates (i.e., to a blob or a tree) as not fo
Chris Rorvick writes:
> Pass all rejection reasons back from transport_push(). The logic is
> simpler and more flexible with regard to providing useful feedback.
>
> Signed-off-by: Chris Rorvick
> ---
Thanks for a reroll.
I do not think they are "masks", by the way. They are set of flags
(i.
Paul Gortmaker writes:
> Currently, if you don't have curl installed, you will get
>
> $ make distclean 2>&1 | grep curl
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-
On Mon, Nov 26, 2012 at 3:50 PM, Matthieu Moy
wrote:
> What's possible is that someone had already merged the branch containing
> "new", got conflicts, and resolved it in favor of "old" somewhere in the
> history of your master branch.
This is exactly what happened. I've actually found a merge of
Antoine Pelisse writes:
> parenthesis are not matching in `builtin_remote_sethead_usage`
> as a square bracket is closing something never opened.
> ---
> This will also break all translation files, should I also send a patch
> to update them ?
"git grep -A2 -e 'remote set-head ' po/" tells me th
Krzysztof Mazur writes:
> Some addresses are passed twice to unique_email_list() and invalid addresses
> may be reported twice per send_message. Now we warn about them earlier
> and we also remove invalid addresses.
>
> This also removes using of undefined values for string comparison
> for inval
Hi guys,
Any further interest on this scalability problem or should I move on?
Thanks,
Uri
On Thu, Nov 8, 2012 at 5:35 PM, Uri Moszkowicz wrote:
> I tried on the local disk as well and it didn't help. I managed to
> find a SUSE11 machine and tried it there but no luck so I think we can
> elimina
Kacper Kornet writes:
>> Is there any interaction between this "pull --reverse-parents"
>> change and possible conflict resolution when the command stops and
>> asks the user for help? For example, whom should "--ours" and "-X
>> ours" refer to? Us, or the upstream?
>
> The change of order of p
Johannes Schindelin writes:
> If you changed your stance on the patch Sverre and I sent to fix this, we
> could get a non-partial fix for this.
This is long time ago so I may be misremembering the details, but I
thought the original patch was (ab)using object flags to mark "this
was explicitly a
Antoine Pelisse writes:
> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
> wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano wrote:
>>> Is this a safe and sane thing to do, and if so why? Could you
>>> describe that in the log message here?
>> Why would fast-export try to export so
Krzysztof Mazur writes:
> In some cases the user may want to send email with "Cc:" line with
> email address we cannot extract. Now we allow user to extract
> such email address for us.
>
> Signed-off-by: Krzysztof Mazur
> ---
> git-send-email.perl | 9 ++---
> 1 file changed, 6 insertions(
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > In some cases the user may want to send email with "Cc:" line with
> > email address we cannot extract. Now we allow user to extract
> > such email address for us.
> >
> > Signed-off-by: Krzysztof Mazu
Hi Junio,
On Sun, 25 Nov 2012, Junio C Hamano wrote:
> From: Johannes Schindelin
> Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
> Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
> Message-ID:
>
>
> (which is $gmane/208946) that says:
>
> Note that
>
>
Patrik Gornicz wrote:
> Just a hunch but your remote's location uses a relative path
> '../linux-2.6.git', perhaps git is messing up what the path is relative
> to.
That makes sense. Git is looking at the URL and not realizing that it's
relative to the home directory.
[remote "upstream"]
[ Jumping back in time ]
Igor Lautar writes:
>> Try this:
>>
>> commit=
>> # Show diff with first parent:
>> git diff "$commit" "$commit"^1
>> # Show diff with second parent:
>> git diff "$commit" "$commit"^2
>
> Yes, change is shown in commit^2, but actual file after merge does not have
> it.
On Mon, Nov 26, 2012 at 3:19 PM, Matthieu Moy
wrote:
> What about "git annotate ^1"?
No change, line version goes back to when file was added.
> Was the merge completely automatic, or were there any conflict?
No conflicts at all. In fact, that particular file was not touched by
one side of mer
Igor Lautar writes:
> git annotate ^2
> - shows line as being modified by a commit done after file was added
> - ie., state I would expect after a merge
What about "git annotate ^1"?
Was the merge completely automatic, or were there any conflict?
--
Matthieu Moy
http://www-verimag.imag.fr/
On Mon, Nov 26, 2012 at 3:03 PM, Matthieu Moy
wrote:
> Your initial message was about the output of "git log". Do you mean that
> the file, on the filesystem, does not have the line introduced by the
> commit?
Yes, sorry if I was not clear enough.
> If so, check the content registered in the rep
> If that's the case, I don't think it should throw a warning even just skip
> them.
Removing the warning seems fine to me.
> Then, in the actual export if some of these objects are referenced the
> export would fail anyway (but they won't).
Of course it will fail to export anything that requir
On Mon, Nov 26, 2012 at 2:23 PM, Antoine Pelisse wrote:
> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
> wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano wrote:
>>> Is this a safe and sane thing to do, and if so why? Could you
>>> describe that in the log message here?
>> Why wou
Igor Lautar writes:
> Yes, change is shown in commit^2, but actual file after merge does not have
> it.
Your initial message was about the output of "git log". Do you mean that
the file, on the filesystem, does not have the line introduced by the
commit?
If so, check the content registered in
On Mon, Nov 26, 2012 at 2:38 PM, Matthieu Moy
wrote:
> Igor Lautar writes:
>> Somewhat, but it does not explain why the file no longer has that
>> change.
>
> It still has, but it's not shown by "git log ", probably because
> one of the parent of the merge commit introduces no change for this
> f
Igor Lautar writes:
> On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
> wrote:
>> The other related question being: does reading the section "History
>> Simplification" in "man git-log" help? ;-)
>
> Somewhat, but it does not explain why the file no longer has that
> change.
It still has, but it'
On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
wrote:
> The other related question being: does reading the section "History
> Simplification" in "man git-log" help? ;-)
Somewhat, but it does not explain why the file no longer has that
change. I can understand omitting history if end result is the
On Mon, Nov 26, 2012 at 2:10 PM, Tomas Carnecky
wrote:
> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar wrote:
>> git log
>> - commit NOT shown in file history any more and file does not have this
>> change
>
> does `git log --full-history ` show the commit?
Indeed it does.
Did the merge wi
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
wrote:
> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano wrote:
>> Is this a safe and sane thing to do, and if so why? Could you
>> describe that in the log message here?
> Why would fast-export try to export something that was pruned? Doesn't
>
Tomas Carnecky writes:
> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar wrote:
>> git log
>> - commit NOT shown in file history any more and file does not have this
>> change
>
> does `git log --full-history ` show the commit?
The other related question being: does reading the section "Hist
On Sun, Nov 25, 2012 at 11:11 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> And are you going to be around to spot them? It seems my patches for
>> git-remote-hg slipped by your watch, because it seems they use stuff
>> specific to python 2.7.
>
> The dev group hasn't decided (in whatever way
On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
>
> I looked at the Makefile. I saw that there are shell variables that collect
> C commands, shell command, Perl commands, an
On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar wrote:
> git log
> - commit NOT shown in file history any more and file does not have this
> change
does `git log --full-history ` show the commit?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
Hi,
This looks really weird and I cannot explain why it occurs.
Setup is as follows:
- origin
- mirror
- local clone
Reference repository is origin from where builds are done etc.
Parallel to that, we keep a mirror that is synced manually
(fetch/merge/push).
I do this from my local clone (wh
On Mon, 26 Nov 2012 04:55:10 +
Carl Smith wrote:
> After suggesting using zip files to move our projects around, I was
> told that you can not zip a git repo without loosing all the history.
> This didn't make sense to me, but two people told me the same thing,
> so I wasn't sure. I think the
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote:
> Kacper Kornet writes:
> > The following patch is an attempt to implement this idea.
> I think "revert" is a wrong word (implying you have already done
> something and you are trying to defeat the effect of that old
> something), a
> Add config pack.graphcompression similar to pack.compression.
> Applies to non-blob objects and if unspecified falls back to pack.compression.
>
> We may identify objects compressed with level 0 by their leading bytes.
> Use this to force recompression when the source and target levels mismatch.
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> fast-export can fail because of some pruned-reference when importing a
>> mark file.
>>
>> The problem happens in the following scenario:
>>
>> $ git fast-export --export-marks=MARKS master
>> (rewrite m
On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>> wrote:
>>> This is a re-roll of the previous series to add support to fetch and push
>>> special modes, and refactor some related code.
>>
>> It seems this
On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac wrote:
> Good idea, thanks. Improved patch is attached.
It is custom on this list to mail the patches, rather than attaching
them, so people can review your changes in-line. You can read more
about it in in git/Documentation/SubmittingPatches.
Cheers,
1 - 100 of 107 matches
Mail list logo
