# Re: Ensimag students working on textconv for blame

2 messages from 2010-05-28 to 2010-05-28. Participants: Diane Gasselin, Junio C Hamano.
Thread: https://gitlist.dev/t/23932

## Diane Gasselin, 2010-05-28 10:27

Subject: Re: Ensimag students working on textconv for blame
Message-ID: <AANLkTinHLoYMgBawxmXpH5XSyJDb_743HEpfCmfqoRHu@mail.gmail.com>
URL: https://gitlist.dev/e/AANLkTinHLoYMgBawxmXpH5XSyJDb_743HEpfCmfqoRHu%40mail.gmail.com
In-Reply-To: <AANLkTimmR6yLLmCy_QvonjjgAp9F012DQb9TYCMiQ0yp@mail.gmail.com>

```
Hi,

Axel, Clément and I are french Ensimag students
( http://ensimag.grenoble-inp.fr/ ) working for the community on the
occasion of an end-of-year project (in equivalent of master 1).
So it is kind of a mini-google summer of code for us.

We are mentored by Matthieu Moy who introduced us in the thread:
http://article.gmane.org/gmane.comp.version-control.git/147487/

We are currently working on a textconv support for git-blame.
We are getting to a first version that we will soon communicate.

Afterwards, we thought about working on git-merge.
Actually, when having some local changes in some files
that would be overwritten by merge, git-merge aborts giving the
first file for which there is a problem. If we commit or stash the
changes on this file and try again to merge, the second file for
which there are some local changes will appear.
What will we try to do is to provide to the user a list of all the files
for which there is a problem before aborting.
Do you think it is a good idea?

Thank you all for your time.

Cheers,
Axel, Clément and Diane

```

## Junio C Hamano, 2010-05-28 23:55

Subject: Re: Ensimag students working on textconv for blame
Message-ID: <7v63277f92.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v63277f92.fsf%40alter.siamese.dyndns.org
In-Reply-To: <AANLkTinHLoYMgBawxmXpH5XSyJDb_743HEpfCmfqoRHu@mail.gmail.com>

```
Diane Gasselin <diane.gasselin@ensimag.imag.fr> writes:

> Afterwards, we thought about working on git-merge.
> Actually, when having some local changes in some files
> that would be overwritten by merge, git-merge aborts giving the
> first file for which there is a problem.

That's a nice bite-sized problem to tackle.  Thanks (and thank you,
Matthieu).

```
