<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Ugh. It’s early, your branches, and describing the problem is making me confused.<div><br></div><div>In all honesty, I think you would benefit from git-flow (<a href="http://nvie.com/posts/a-successful-git-branching-model/_">http://nvie.com/posts/a-successful-git-branching-model/_</a>, with some sort of web (bitbucket, github, gitlab, etc) front end so you can visually see transactions. Hardcore and only want the console? no problem add this to your git config</div><div><span class="println_entry_content"><span id="println_entry_body"><pre class="line-pre">git config --global --add alias.lol "log --graph --decorate --pretty=oneline --abbrev-commit --all"</pre></span></span><div><br></div><div>then you can issue a git lol.</div><div><br></div><div>This will give you a visual eyeglass into when what merged, and who did what, etc.</div><div><br></div><div>I think you should have a ‘develop’ branch which is where your linux box gets deployed from. Each ‘feature’ you develop should be a branch based off of develop such as feature/JIRA_NUM-my_new_cool_button/</div><div>write some code</div><div>maybe make a few commits</div><div>add a library</div><div>commit</div><div>add an image</div><div>commit</div><div>finito!</div><div>git flow feature publish feature/JIRA_NUM-my-new-cool-button./</div><div><br></div><div>Feature published</div><div><br></div><div>When happy, merge your feature branch into develop</div><div>Deploy develop to ‘environment’</div><div><br></div><div>When ready for a release, either create a release/release-1 branch, or merge from develop into master</div><div><br></div><div><div>I THINK the problem/trick you are describing below is that you need to rebase from another branch, in gitflow your rewind branches would be feature branches, developers merge into ‘develop' when they are ‘feature’ complete. </div><div><br></div><div>Hope this sort of helps, I’m just having a hard time drawing a picture in my head of when events occurred, what events need to be merged with what.</div><div><br></div><div><br></div><div><br></div><div>On Apr 17, 2014, at 12:00 AM, John Johnson <<a href="mailto:jvj@golden.net">jvj@golden.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#ffffff" text="#000000">
<big>Earlier I asked:<br>
<i>What happens if I have modified a file in one of the branches?<br>
Say it is a file accessible through FF with
/localhost/projectName/indexTest.php<br>
</i><br>
I think I have an answer.<br>
$ git checkout rewind_2f7c343 (switch to branch)<br>
test in FF: /localhost/projectName/indexTest.php<br>
behaviour is w (this is a problem)<br>
<br>
modify file indexTest.php<br>
w/o commit<br>
<br>
test in FF: /localhost/projectName/indexTest.php<br>
behaviour is x (problem of w is gone)<br>
<br>
$ git checkout rewind_f9a4506</big><big> (switch to branch)</big><br>
<big>test in FF: /localhost/projectName/indexTest.php<br>
behaviour is x (was y + w before mods)<br>
<br>
$ git checkout rewind_ad95724</big><big> (switch to branch)</big><br>
<big>test in FF: /localhost/projectName/indexTest.php<br>
behaviour is x (was z + w before mods)<br>
<br>
behaviour x is from the uncommited (staged?) file modified under </big><big>rewind_2f7c343</big><br>
<big><br>
$ git checkout rewind_2f7c343</big><big> (switch to branch)</big><br>
<big>$ git commit -a<br>
to commit changes to indexTest.php<br>
<br>
test in FF: /localhost/projectName/indexTest.php<br>
</big><big>behaviour is x (problem of w is gone)<br>
</big><big><br>
$ git checkout rewind_f9a4506</big><big> (switch to branch)</big><br>
<big>test in FF: /localhost/projectName/indexTest.php<br>
behaviour is y + w (problem w is present)<br>
<br>
$ git checkout rewind_ad95724</big><big> (switch to branch)</big><br>
<big>test in FF: /localhost/projectName/indexTest.php<br>
behaviour is z + w (problem w is present)<br>
<br>
Now, the trick I have at hand is to merge the changes in indexTest.php
made in rewind_2f7c343 with the other branches.<br>
And do this so that only the problem with behaviour w is addressed,
i.e. without affecting the other behaviours present in the other
branches.<br>
<br>
Learning by doing.<br>
Hopefully, in the right direction.<br>
<br>
Thanks<br>
John Johnson<br>
</big><br>
<br>
On 2014-04-16 22:16, John Johnson wrote:
<blockquote cite="mid:534F3965.4080905@golden.net" type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<big>The question below (re: git 'pull' of a specific file [w/o
overwriting current]) remains at least for me, open.<br>
<br>
But I now, have one or more advanced (I think) questions.<br>
<br>
My environment: Windows XP on one PC. Linux Ubuntu on another. The
Linux PC is the intended the deployment target.<br>
Development is on the Windows XP PC under XAMPP. Git for Windows is
installed on the Windows PC. (Not yet on the Linux PC.)<br>
<br>
It had to happen. Somewhere in the past couple of days, and after a few
Git commits things went sideways.<br>
And I find myself having to do, what I call a 'rewind', i.e. a git
branch to an earlier commit (maybe more than one branch).<br>
<br>
A week or two ago, the Master was branched to newBranch, which became
the main development path. The Master is now dated and useless.<br>
(newBranch? OK OK so I am not very creative with the naming!)<br>
<br>
And now, while under the branch newBranch, I have executed one or more
commands like:<br>
$ git checkout -b rewind_f9a4506 f9a4506<br>
Where f9a4506 is the git assigned commit ID.<br>
(rewind_f9a4506? Again, I am not being creative with the branch naming,
but at least this one carries more information than 'newBranch'.)<br>
<br>
When the branch command is executed I see the message:<br>
Switched to a new branch 'rewind_f9a4506'<br>
<br>
This is all well and good in the Git bash window.<br>
<br>
And I can, for various reasons, navigate between the branches with the
commands:<br>
$ git checkout newBranch<br>
$ git checkout rewind_f9a4506<br>
$ git checkout rewind_ad95724<br>
(Note: I am exploring and have done no mods or commits in these
branches.)<br>
<br>
It appears that when XAMPP and using FF, /localhost/projectName/ into
the browsers address bar brings up the index.php for the branch
currently active in the Git bash window.<br>
<br>
Is this a correct assumption?<br>
I can understand the 'view' of the files as given through</big><big>
the Git bash window.</big> <big>But I am not clear as to how Windows
apps, e.g. a text editor, and XAMPP find the files associated with the
branch currently active in he Git bash window.</big><br>
<big><br>
What happens if I have modified a file in one of the branches? <br>
Say it is a file accessible through FF with
/localhost/projectName/indexTest.php<br>
<br>
I have not yet got to the stage where I will update the Master or
newBranch with one of the branches.<br>
Or create and update a remote repo, i.e. on the Linux PC.<br>
<br>
As said earlier: t</big><big>ips / comments / guidelines / advice /
etc. from those who have gone
before me are welcome.<br>
</big><big><br>
Thanks<br>
John Johnson<br>
</big><br>
On 2014-04-16 11:33, John Johnson wrote:
<blockquote cite="mid:534EA2C3.40103@golden.net" type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<big>This is definitely, not an an "advanced" question.<br>
But it is one for which I could not an answer on the Google or in Git
tuts.<br>
<br>
Using Git, can one, without creating a branch, pull a file from an
earlier commit?<br>
And (asking a lot) store the pulled file in a place other than the
current working directory?<br>
<br>
Unless I need to do some more reading, git commands, revert pull and
checkout all seem to operate on the repo as a whole and not on
individual files.<br>
<br>
Tips / comments / guidelines / advice / etc. from those who have gone
before me are welcome.<br>
<br>
Thanks<br>
JohnJ<br>
<br>
</big><br>
<br>
On 2014-04-15 21:44, Chris Frey wrote:
<blockquote cite="mid:20140416014420.GA8521@foursquare.net" type="cite">
<pre wrap="">On Tue, Apr 15, 2014 at 08:47:41PM -0400, John Johnson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">A tip on Git that I read somewhere was to develop a consistent style
in the git commit messages, e.g. git -am [message text], so as to
make subsequent searches easier. For example, if one was using an
issue tracking system with issues SCR 1024 SCR 2031 SCR 112 being
active and the commit was to combine repairs that addressed these
issues, the commit message could be: git commit -am "issues: SCR
1024 SCR 2031 SCR 112" or similar.
</pre>
</blockquote>
<pre wrap="">That "git commit -am" worries me. :-) My usual process is:
git add -p
git commit # with editor
This allows more detailed commit messages than just a single line.
And the git-add with '-p' makes sure you only commit the changes you
intend. You can also break your current workspace into multiple
commits, making them small and logical.
Also, in git, the first line is special, as you probably know.
But there exists a --grep option in commands such as git-log, for
searching commit messages. For example, if your commit message said:
driver: fixed off-by-one error in buffer init
Changed code to use sizeof() instead of hard coded value.
Fixes SCR 1024, SCR 2031, SCR 112
Now, if you do:
git shortlog
you get a nice brief description of your changes, yet you still have
your bug tracking IDs in the commits, so that this is possible:
git log --grep="SCR 2031"
- Chris
_______________________________________________
kwlug-disc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
-----
Checked by AVG - <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.avg.com/">www.avg.com</a>
Version: 2014.0.4355 / Virus Database: 3882/7345 - Release Date: 04/14/14
</pre>
</blockquote>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
kwlug-disc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br><p class="" avgcert="" align="left"><br>
Checked by AVG - <a moz-do-not-send="true" href="http://www.avg.com/">www.avg.com</a><br>
Version: 2014.0.4355 / Virus Database: 3882/7349 - Release Date:
04/15/14</p>
</blockquote>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
kwlug-disc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br><p class="" avgcert="" align="left"><br>
Checked by AVG - <a moz-do-not-send="true" href="http://www.avg.com/">www.avg.com</a><br>
Version: 2014.0.4355 / Virus Database: 3882/7354 - Release Date:
04/16/14</p>
</blockquote>
<br>
</div>
_______________________________________________<br>kwlug-disc mailing list<br><a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br>http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org<br></blockquote></div><br></div></body></html>