threads / discuss / 12981

newbie with broken workflow

Subject: newbie with broken workflow

## tl;dr

6 messages between Apr 3, 2008 and Apr 4, 2008.

replies: 5people: 3as markdown or json

James Kingston· Apr 3, 2008, 21:45 UTC · lore

I am a few days into git and have settled into a workflow that is apparently very broken, and I'd appreciate it if someone with a more experienced eye can point out where I went wrong.

The official SCM tool at my work is ClearCase Remote Client, and it's vile... pessimistic locking, huge bureaucracy just to create a branch (I love experimental branches), no licenses for the native client. My plan was to use git (Git-1.5.4-preview20080202.exe) to track my clearcase view directory, and push changes into that repo when convenient from my working directory repo (clearcase makes non-checkedout files read only, which makes working directly in the view directory Ugly).

Here is a timeline of how I tried to do this:

/c> cd /c/cc /c/cc> git init /c/cc> git add * /c/cc> git commit /c/cc> mkdir /c/wd /c/cc> cd /c/wd /c/wd> git clone /c/cc /c/wd> cd cc/ /c/wd/cc> ls /c/wd/cc> vi config.ini /c/wd/cc> git checkout -b config_changes /c/wd/cc> git diff /c/wd/cc> git add config.ini /c/wd/cc> git commit /c/wd/cc> git checkout master /c/wd/cc> git merge config_changes /c/wd/cc> vi config.ini /c/wd/cc> git push /c/cc /c/wd/cc> cd /c/cc /c/cc> vi config.ini # doesn't show the change made in experimental branch, though gitk shows the patch /c/cc> git status # says that config.ini has been modified /c/cc> git add config.ini # grasping as straws /c/cc> git commit # changes nothing, as far as I can tell /c/cc> git reset --hard #still changes nothing. My diffs are there in the log, just out of reach

I have much to learn, but in the short term I just need to get those changes into clearcase so QA can pull them

Santi Béjar· Apr 3, 2008, 22:03 UTC · re: James Kingston · lore

Re: newbie with broken workflow

On Thu, Apr 3, 2008 at 11:45 PM, James Kingston <james.kingston@gmail.com> wrote: [...]

Show 19 quoted lines

>
>  /c>     cd /c/cc
>  /c/cc>  git init
>  /c/cc>  git add *
>  /c/cc>  git commit
>  /c/cc>  mkdir /c/wd
>  /c/cc>  cd /c/wd
>  /c/wd>  git clone /c/cc
>  /c/wd>  cd cc/
>  /c/wd/cc>  ls
>  /c/wd/cc>  vi config.ini
>  /c/wd/cc>  git checkout -b config_changes
>  /c/wd/cc>  git diff
>  /c/wd/cc>  git add config.ini
>  /c/wd/cc>  git commit
>  /c/wd/cc>  git checkout master
>  /c/wd/cc>  git merge config_changes
>  /c/wd/cc>  vi config.ini
>  /c/wd/cc>  git push /c/cc

git push updates the branches, not the working copy, so:

cd /c/cc git pull /c/wd/cc HEAD

Show 9 quoted lines

>  /c/wd/cc>  cd /c/cc
>  /c/cc>  vi config.ini # doesn't show the change made in experimental
>  branch, though gitk shows the patch
>  /c/cc>  git status # says that config.ini has been modified
>  /c/cc>  git add config.ini # grasping as straws
>  /c/cc>  git commit # changes nothing, as far as I can tell
>  /c/cc>  git reset --hard #still changes nothing.  My diffs are there
>  in the log, just out of reach
>

Santi

James Kingston· Apr 3, 2008, 23:41 UTC · re: Santi Béjar · lore

Re: newbie with broken workflow

On Thu, Apr 3, 2008 at 5:03 PM, Santi Béjar <sbejar@gmail.com> wrote:

Show 6 quoted lines

>  git push updates the branches, not the working copy, so:
>
>  cd /c/cc
>  git pull /c/wd/cc HEAD
>  Santi
>

Thank you.  I also found the FAQ in the wiki, so the reasons are clear.

Daniel Barkalow· Apr 4, 2008, 00:05 UTC · re: James Kingston · lore

Re: newbie with broken workflow

On Thu, 3 Apr 2008, James Kingston wrote:

Show 44 quoted lines

> I am a few days into git and have settled into a workflow that is
> apparently very broken, and I'd appreciate it if someone with a more
> experienced eye can point out where I went wrong.
> 
> The official SCM tool at my work is ClearCase Remote Client, and it's
> vile... pessimistic locking, huge bureaucracy just to create a branch
> (I love experimental branches), no licenses for the native client.  My
> plan was to use git (Git-1.5.4-preview20080202.exe) to track my
> clearcase view directory, and push changes into that repo when
> convenient from my working directory repo (clearcase makes
> non-checkedout files read only, which makes working directly in the
> view directory Ugly).
> 
> Here is a timeline of how I tried to do this:
> 
> /c>	cd /c/cc
> /c/cc> 	git init
> /c/cc> 	git add *
> /c/cc> 	git commit
> /c/cc> 	mkdir /c/wd
> /c/cc> 	cd /c/wd
> /c/wd>	git clone /c/cc
> /c/wd>	cd cc/
> /c/wd/cc>  ls
> /c/wd/cc>  vi config.ini
> /c/wd/cc>  git checkout -b config_changes
> /c/wd/cc>  git diff
> /c/wd/cc>  git add config.ini
> /c/wd/cc>  git commit
> /c/wd/cc>  git checkout master
> /c/wd/cc>  git merge config_changes
> /c/wd/cc>  vi config.ini
> /c/wd/cc>  git push /c/cc
> /c/wd/cc>  cd /c/cc
> /c/cc> 	vi config.ini # doesn't show the change made in experimental
> branch, though gitk shows the patch
> /c/cc> 	git status # says that config.ini has been modified
> /c/cc> 	git add config.ini # grasping as straws
> /c/cc> 	git commit # changes nothing, as far as I can tell
> /c/cc> 	git reset --hard #still changes nothing.  My diffs are there
> in the log, just out of reach
> 
> I have much to learn, but in the short term I just need to get those
> changes into clearcase so QA can pull them

So you should actually do:

/c/wd/cc> cd /c/cc /c/cc> git pull ../wd/cc

But wouldn't that fail, because the files are read-only?

I think you'd do:

/c/cc> git fetch ../wd/cc /c/cc> git diff --name-only HEAD FETCH_HEAD

Tell ClearCase you want to edit those files

/c/cc> git merge FETCH_HEAD

Commit your ClearCase stuff

Also, IIRC, the sort of normal workflow for dealing with foreign SCMs that need local working directories is actually to put them in .git/info/something, and use git diff to get the changes in each of your git commits and git apply (using it like "patch", but smarter) to modify the working directory.

	-Daniel
*This .sig left intentionally blank*

James Kingston· Apr 4, 2008, 14:08 UTC · re: Daniel Barkalow · lore

Re: newbie with broken workflow

On Thu, Apr 3, 2008 at 7:05 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:

>  /c/wd/cc> cd /c/cc
>  /c/cc> git pull ../wd/cc
>
>  But wouldn't that fail, because the files are read-only?

Actually, I just tried and it worked beautifully. The directory is writable, so git replaces rather than modifies the files. Then I can use CCRC to search for hijacked files, check them out in one swoop with the option to keep my modifications, then check them all in as a group.

Daniel Barkalow· Apr 4, 2008, 16:30 UTC · re: James Kingston · lore

Re: newbie with broken workflow

On Fri, 4 Apr 2008, James Kingston wrote:

Show 11 quoted lines

> On Thu, Apr 3, 2008 at 7:05 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >  /c/wd/cc> cd /c/cc
> >  /c/cc> git pull ../wd/cc
> >
> >  But wouldn't that fail, because the files are read-only?
> 
> Actually, I just tried and it worked beautifully.  The directory is
> writable, so git replaces rather than modifies the files.  Then I can
> use CCRC to search for hijacked files, check them out in one swoop
> with the option to keep my modifications, then check them all in as a
> group.

Ah, yes, I guess that would work. Although I suspect that it would be annoying to recover if you failed to get the locks for any of them, since you're missing CC's expected path for conflict resolution.

	-Daniel
*This .sig left intentionally blank*