Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:52:27
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson [off-list ref] wrote:
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
quoted
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
Every file in the latest working tree is also a tracked file. The
files are being added to the git repo, but not removed from it.
In other words, the biggest set of files is the latest working tree,
and the smallest one is the first commit.
Dario
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:52:27
On Tue, Nov 08, 2011 at 11:17:27AM -0300, Dario Rodriguez wrote:
On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson [off-list ref] wrote:
quoted
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
quoted
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
Every file in the latest working tree is also a tracked file. The
files are being added to the git repo, but not removed from it.
In other words, the biggest set of files is the latest working tree,
and the smallest one is the first commit.
Dario
I can't see a pure git way of doing this. However, you already seem to
use git in a very hackish-way. So here's a quick n' dirty solution (that
is not very efficient).
(not tested example code, that should be runned from the root-gitdir.):
#!/bin/sh
git reset --hard HEAD
for f in `find`
do
commit=`git log $f | grep commit | tail -1`
git checkout $commit $f
done
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
On Tue, Nov 8, 2011 at 12:00 PM, Fredrik Gustafsson [off-list ref] wrote:
On Tue, Nov 08, 2011 at 11:17:27AM -0300, Dario Rodriguez wrote:
quoted
On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson [off-list ref] wrote:
quoted
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
quoted
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
Every file in the latest working tree is also a tracked file. The
files are being added to the git repo, but not removed from it.
In other words, the biggest set of files is the latest working tree,
and the smallest one is the first commit.
Dario
I can't see a pure git way of doing this. However, you already seem to
use git in a very hackish-way. So here's a quick n' dirty solution (that
is not very efficient).
(not tested example code, that should be runned from the root-gitdir.):
#!/bin/sh
git reset --hard HEAD
for f in `find`
do
commit=`git log $f | grep commit | tail -1`
git checkout $commit $f
done
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
Yes, it's similar to my approach, except that I used 'git ls-files'
and 'git log --format=%H' to get the commit hash for each file
instead. Seems dirty, but reasonable if you think the git way.
Thank you,
Dario