[git-users] Amending a commit into different branches
In playing around on scenarios in which I often find myself, I have the following repo: master dev | | v v A --- B --- C In an ideal world, the commit path would have had parts of the C commit split into several bugfix branches instead of directly committing on dev, resulting in master devbugs/5 | || v vv A -- B Ca ... (future work on bug #1234 here) \ - Cb ... (future work on bug #2345 here) ^ | bugs/7 allowing for further dev on the bug-fixes until they're really ready for merging back into dev. I played around with amend/stash/rebase and eventually got the repo looking how I wanted, but had a nagging feeling there was a better work-flow. Transcript below if you want to play along at home. Is there a better way to do this? Thanks, -tkc mkdir g;cd g git init seq 10 file.txt git add file.txt; git commit -m Initial git co -b dev sed -i '3s/.*/ /' file.txt git commit -am dev: changed line 3 sed -i '5s/.*/ /' file.txt sed -i '7s/.*/ /' file.txt git commit -am partial work on bugs 5 and 7 git reset HEAD^ # whoops git co -b bugs/5 git add -p file.txt # select stuff for bug 5 git commit -m partial work on bug 5 git stash git co -b bugs/7 dev git stash pop git add -p file.txt # select stuff for bug 7 git commit -m partial work on bug 7 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Amending a commit into different branches
On 06/19/12 07:52, Thomas Ferris Nicolaisen wrote: I took the liberty of monospacing your ascii-art below: master dev | | v v A --- B --- C Not sure what happened there...according to my Sent folder, they went out from Thunderbird on my end as monospace/plaintext and based on what I see in gmane, it came out correctly there. Sorry if something was set wrong. I think your approach seems fine. A different way of doing it is to hold off reseting the dev branch (or copy the commitish of it and use that), and get the changes into the branches by checking them out, instead of keeping them in the work-tree/stash: ... git checkout -p dev # select stuff for bug 5 Nice...I hadn't read about checkout -p and have wanted something like this on occasion. Thanks! git reset HEAD~1 # you could've done first, but then you need to copy the commitish first, and use that when you use checkout -p above, instead of dev Of course, with this approach, I need to sift through the changes in dev twice. Yeah, my first meandering pass at this looked a little like this (only considerably less elegant, not knowing about checkout -p as mentioned above), creating a temporary branch/tag pointing at the commitish rather than noting the hash. The stash was the best way I could come up with to hold on to changes I hadn't yet applied, pull some out into their own branch, then re-stash them, rather than sifting through all the changes every time. I appreciate your thoughts on other ways to do it. Thanks! -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: how to merge to separate repositories.
On 06/28/12 12:57, Nicolas Bock wrote: I checked out the most recent version from CVS and made that the initial commit of our git repository. This unfortunately meant that we lost all history prior to the switch. We would now like to add that missing history into git. I converted the CVS to git and have two git repositories now, one that is the converted CVS, and one that contains all changes since then. How do I merge the two? From my understanding, this can be done as follows: bash$ INITIAL=/path/to/git/repo/forcvs/snapshot/ bash$ CVS_FULL=/path/to/git/repo/for/full/cvs/history/ bash$ cd $INITIAL bash$ git branch all_branches_to_deal_with.txt bash$ git remote add cvs_full file://$CVS_FULL bash$ git pull cvs_full at this point you now have two disjoint histories in the same $INITIAL repository. Then for each of the branches you have in the $INITIAL repo (noted in all_branches_to_deal_with.txt), rebase that branch onto the master branch of the $CVS_FULL repo bash$ for branchname in master some_dev_branch some_other_branch; do git checkout $branchname; git rebase remotes/cvs_full/master ; done NOTE: THIS WILL MODIFY ANY PUSHED HISTORY and may peeve folks with whom you share the repo. But that's what you're asking for: the ability to change history and introduce edits before the initial (snapshot) checkin. Read git help rebase carefully about what this. At least, it worked and did what you asked in test repos here. The only thing I noticed is that, if there was modern history of branches that were then merged back in, that branching/merging was squashed in the resulting history. As always, clone off copies of both archives and work from those for testing/exploring. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: how to merge to separate repositories.
On 06/28/12 13:44, Philip Oakley wrote: You can use Grafts Always happy to learn new git tricks. Thanks! This is a far better solution than my rebasing, though with similar (albeit easier and cleaner) results if you plan to push anywhere. From what I read, the grafting doesn't get pushed, so you have to then do a fast-export|fast-import pipeline to a virgin repository in order to get a clean/pushable history. But like a rebase, this history won't exist elsewhere, so others' pulls will get parallel/unrelated histories. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Marking code blocks consistently ignored for add/commit
I've got a number of Python modules where the debugging code changes on a regular basis, but is of no relevance to the history of the file. For a snippet, it might be something like def real_code(x): return do_stuff(x) # version everything above the next line if __name__ == __main__: # everything from here on filename = r/tmp/thing # should be ignored f = real_code(x) # every time print f[some arbitrary test case] The files are data-source files from providers, and the value I want to check (the subscripting in this case) is usually some case with which we're having a particular problem. Because it's just there to test new cases in the providers' data, and the tests aren't available in every source data file (we don't keep huge histories of the gigs of files/data to allow retesting later). Currently, when I check it in, I do an add -p and just skip the hunks after the if __name__ ==. I was wondering if there was a better (i.e., automatic) way to delimit that a certain segment of the file should never be considered changed and that git should ignore it when adding/committing the file. Thanks, -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Marking code blocks consistently ignored for add/commit
On 07/08/12 11:13, Lars Pensjö wrote: I think this is a common problem. You have changes in the code that you do not want to check in. I use git gui for this. It is easy to select what hunks, or even individual lines, that shall be included in the index. As mentioned, I currently just use add -p to stage everything but the designated sections. It's what made my shift from what the heck is this annoying Index thing to oh, now I can't go back to using other [DC]VCS tools without this. It's also not overly onerous on a case-by-case basis but after several hundred checkins, it's gotten a tad tedious (the alternative is forgetting and then having the pointless change show up in the revision history that gets pushed to SVN). It is not an automated solution, but it is quick, flexible and easy enough for me. However, I was hoping for some method of marking the file (or perhaps an add/commit hook) that would allow me to automatically ignore a section of code every time without manual intervention. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Creating an initial git repository
On 07/19/12 06:54, P Rouleau wrote: I suggest to read http://hginit.org that URL was failing for me. I presume you mean http://hginit.com -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Bug? status --porcelain only quotes spaces in added files
On 07/24/12 12:07, Graham Jans wrote: On Tuesday, 24 July 2012 04:37:47 UTC-7, Tim Chase wrote: $ touch a 1.txt $ touch a 2.txt $ touch 'a 3.txt' $ git add a 1.txt $ git status --porcelain A a 1.txt ?? \a 3.txt\ ?? a 2.txt == Yeah, so in your case, the behavior is at least consistent: it doesn't put quotes around filenames in spaces in either the 'a 1' or 'a 2' case. (In the case of 'a 3'... that's just odd, I've never seen anyone put quotes _in_ a filename before! ;) ) I believe that on Posix systems, any ASCII character other than / and NUL can appear in a filename, so it can create all manner of problems when your filename has sociopathic newlines, tabs, escape (gotta love ANSI escape sequences in filenames), quotes, backticks, etc. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] misleading diff hunk-header
On 08/21/12 07:19, Konstantin Khomoutov wrote:
On Mon, 20 Aug 2012 20:49:48 -0500
Tim Chase g...@tim.thechases.com wrote:
tl;dr version: diff.{type}.xfuncname starts searching backwards in
from the beginning of the hunk, not the first differing line.
This list is for helping inexperienced Git user master Git itself.
Please report any bugs to the main (devel) Git list which is
git at vger.kernel.org
(More info is at http://vger.kernel.org/vger-lists.html#git)
I guess before reporting it as a bug, I was hoping to get
confirmation whether it was as-designed, or if it really was a bug.
But if it sounds sufficiently buggy, I'll gladly take it there.
-tkc
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
[git-users] Re: how to to check if a branch has changes not present in master?
On 08/28/12 03:13, Fred wrote: is there a way to check if a branch doesn't introduce changes, which are not in master. I'm partial to git diff my_branch ^master which would find all the changes on my_branch that aren't yet on master. This is an open syntax so you can request changes that are on my_branch_a, but aren't on master or on my_branch_b with git diff my_branch_a ^my_branch_b ^master -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: how to to check if a branch has changes not present in master?
On 08/28/12 05:47, Tim Chase wrote: On 08/28/12 03:13, Fred wrote: is there a way to check if a branch doesn't introduce changes, which are not in master. I'm partial to git diff my_branch ^master which would find all the changes on my_branch that aren't yet on master. This is an open syntax so you can request changes that are on my_branch_a, but aren't on master or on my_branch_b with git diff my_branch_a ^my_branch_b ^master Additionally, I find the diff version somewhat hard to read unless the delta is small, but the same syntax works for log: git log my_branch ^master ^my_branch_b which can give you a higher level view of the changes. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] More details on merge-driver=union
I've read the somewhat sparse documentation in gitattributes(5) on the union merge driver, but on #git I was cautioned that there may be unexpected behaviors. My use-case is to consolidate (usually[*]) append-only mbox files that might conflict when different messages are added within various checkouts; the resolution being keep both messages, duh. Are there other places/sites I can learn more about union? My google-fu hasn't found any further information and I was wondering what I should be watching for. Thanks, -tkc [*] Yes, in theory, messages should be deletable from the mbox, but that's an edge case I'm willing to hand-tweak if needed. And in all likelyhood, git does would do the right thing anyways. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Why do I have to be a source control engineer just to be a software developer?
On 10/29/12 17:31, kramer.newsreader wrote: I am a fairly experienced developer and I have never had issues working with source control tools before git. I take a new job. I am working with git. I am thinking about quitting over having to use it. I'll admit that I too took about 4 or 5 goes at learning git before it finally sunk in and I found I could do things natively with git that were either impossible or at least quite difficult in other VCS tools. Others have addressed most of your questions, but I didn't see this one get answered yet: Every source control tool I have used before has an easy command that says: Use these changes right here. Yes there are conflicts, but these are correct. You have to intercept these at the point of the conflict. Usually a merge or pull. You can use the strategy option to say mine, dagnabbit! $ git merge --no-commit -s ours some_other_branch # survey the merge results $ git commit -m Merged in some_other_branch I don't know which other every source control tool you're talking about, as I don't recall seeing (and thus haven't used) such in any of the VCSes I've used (git, svn, hg, bzr, or «shudder» Source Safe). That said, I almost *never* want the ours strategy. If there are conflicts, I want to review them and make an informed choice about the result. Why do I have to be a source control engineer just to be a software developer? You can get by with just a handful of commands for basic activities. Most of my work involves just the following: init/clone, status, log, commit, add, push, fetch/pull. Once you have these, you can replicate what most of my [current past] coworkers have used source-control for. When you get to more advanced requirements (branching/merging, editing history, partial commits, multiple remotes, etc), git is there for you. Branching/merging adds another two commands (unsurprisingly, branch and merge, though I suppose cherry-pick might also be used here). Editing history adds rebase for most of what I do. So you start off with 7-9 basic commands, then add/learn more as your requirements grow. -tkc -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: is it possible to make ``git add --patch`` use arbitrary diffs?
On 11/02/12 10:15, Andrej wrote: ``git add -p`` allows to interactively decide what is to be staged. It shows hunks of code to you much like ``git diff`` would do. The question is: is it possible somehow to interactively stage arbitrary differences other than diffs between working tree and HEAD commit (or actually staging area)? Is something like ``git diff tagA branchB | git add -p`` possible? Verbatim, it is not. But is it possible to put it another way somehow? My previous reply did something upon sending so I don't know if it made it through. It sounds like you want cherry-pick, optionally stashing your changes beforehand: git checkout branchA # target branch git stash save Changes to preserve # optional git cherry-pick tagA..branchB -tkc --
[git-users] Re: /opt/git folder
On 11/22/12 06:28, Konstantin Khomoutov wrote: So, to answer the original question, Git *might* be installed under /opt, when doing manual compilation, but this is somewhat odd due to a number of reasons--it's always better to first try installing Git from a ready-made binary package. Every sensible OS has Git packaged, and it's even available for Windows. So when one installing Git on the server, the first thing to try is to install it using the usual OS's means, like doing `apt-get install git` or `yum install git` or whatever applies. The big exception is when running on older boxes. I admin on older Debian box where 1.5.6.5 is the latest version in the repos, so building from source gets a LOT of good stuff in git (i.e., makes git usable :). That said, I agree that I'd put it in /usr/local/... rather than /opt -tkc --
[git-users] Re: git - svn migration question
On 12/20/12 02:22, Thomas Ferris Nicolaisen wrote: On Thursday, December 20, 2012 5:35:56 AM UTC+1, Daniel Pomerantz wrote: git svn clone svn_url --authors-file=users.txt --no-metadata -s Git_Repo_Name Any reason why you are not using the --stdlayout argument? This is key for converting a standard layout SVN (trunk/branches/tags) into branches in Git. Just for the record, Daniel *is* using -s to get the stdlayout as you yourself use: git svn clone -s foo-fetching :-) -tkc --
[git-users] rev-parse --is-inside-work-tree never returns false?
I was playing around with some of the information that rev-parse can return and just tried --is-inside-work-tree to see what it would return. As expected, in my working-dir $PROJ, it returns true. Same for within $PROJ/.git and $PROJ/dir_with_nothing_tracked However, when I try git rev-parse --is-inside-work-tree outside my repo, I get fatal: Not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). According to my reading of the docs/man-pages, I should get false instead. Under what conditions should rev-parse return false? In this case, I've got my user directories mounted on /home and a test repo in $PROJ=/home/tim/tmp/g so the error occurs in /home/tim and /home/tim/tmp but returns true in /home/tim/tmp/g /home/tim/tmp/g/.git and /home/tim/tmp/g/dir_with_nothing_tracked Thanks, -tkc PS: running 1.7.10.4, FWIW, so if this has been fixed more recently, I'd be happy to just get a already fixed in $NEWER_REV. --
[git-users] Re: rev-parse --is-inside-work-tree never returns false?
On 01/15/13 00:25, Thomas Ferris Nicolaisen wrote:
On Tuesday, January 15, 2013 3:24:34 AM UTC+1, Tim Chase wrote:
However, when I try git rev-parse --is-inside-work-tree outside my
repo, I get
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
According to my reading of the docs/man-pages, I should get false
instead. Under what conditions should rev-parse return false?
As far as I understand, there are three related queries here:
1. is-inside-git-dir
2. is-inside-work-tree
3. is-bare-repository
They are used to discern whether you are inside the repo/.git dir, or in
the work-tree.
If you are in a bare repository, the first one will happen to always be
true, but if you want to know whether you're in a bare repository or not,
the third one is the one to use.
Ah, okay, so some further testing then shows the following results:
tim@bigbox:~/tmp/git_test$ for loc in '.' bare_repo/ nonbare_repo/
nonbare_repo/.git nonbare_repo/empty_dir/ ; do pushd $loc 21
/dev/null; echo In $loc; for test in is-inside-git-dir
is-inside-work-tree is-bare-repository; do echo -n ${test}: ; git
rev-parse --${test}; done; popd 21 /dev/null; echo
''; done
In .
is-inside-git-dir:fatal: Not a git repository (or any parent up to
mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
is-inside-work-tree:fatal: Not a git repository (or any parent up to
mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
is-bare-repository:fatal: Not a git repository (or any parent up to
mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
In bare_repo/
is-inside-git-dir:true
is-inside-work-tree:false
is-bare-repository:true
In nonbare_repo/
is-inside-git-dir:false
is-inside-work-tree:true
is-bare-repository:false
In nonbare_repo/.git
is-inside-git-dir:true
is-inside-work-tree:false
is-bare-repository:false
In nonbare_repo/empty_dir/
is-inside-git-dir:false
is-inside-work-tree:true
is-bare-repository:false
So EVERYTHING outside the repo fails. The --is-inside-work-tree
does return false (contrary to what I remember testing earlier)
inside .git, and in a bare repo. Okay, that makes sense. Thanks!
-tkc
--
