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
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
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
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 mer
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?
Ind
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
7 matches
Mail list logo
