Re: [git-users] Recreating repo structure without content?
On Wed, 2017-09-27 at 22:41 +0100, Philip Oakley wrote: > In the fast export there is the --anonymise > capability. > > > > Have a look at that. > > > > https://git-scm.com/docs/git-fast-export#git-fast-export---anonymize > > https://git-scm.com/docs/git-fast-export#_anonymizing Awesome! Thanks Philip. I needed to run it on a bare clone: if I ran it on my local repo it only exported local branches... which I guess makes sense in retrospect but it would be useful if the help page had mentioned it explicitly. However no big deal it didn't take me long to figure it out. Now to see if this anonymized version shows the bug... Cheers! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Recreating repo structure without content?
Hi all. I'm wondering if anyone has a script or something that will allow me to create a new repository which recreates the commit structure (parent/child, branches, merges) of an existing repository, but with obfuscated content. It's OK if this is slow. My goal is to provide a test case that can reproduce a failure that appears only in our long-lived and complex Git repository, without having to hand over the actual content of the Git repository. Obviously the SHAs would not be the same, but that's not relevant (I'm sure). My suspicion is that the problem is caused by the very complex spaghetti branching structure we used to live with back in 2011/2012, before we imposed sanity. Thanks for any pointers! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] What files have changed between local and remote repo?
On Fri, 2017-06-23 at 12:41 -0700, Nic Attard wrote: > After being on the macbook all day, when I get home I'd like to see > what is out of sync between my windows repo and the remote repo. I > know I can do this with "git diff master origin/master" but this > shows all the line level changes, is there a way to display only > files that are out of sync, without showing the actual line level > changes? You can use the --stat option with git diff (and other Git commands that can show differences, such as "git log" and "git show"). That will show you one line for each file changed, and the number of lines added and removed per file, rather than showing the full lines. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why does git tell me a gif file needs merge - how would you ever merge a gif file
On Tue, 2017-04-04 at 16:12 -0700, bestbrightestandthens...@gmail.com wrote: ok, looks like I did everything correctly except that I switched directories before i did the git checkout -b branch1 command so I will see what happens next -- i guess i need to specify some files for the new branch (as for item 2. I used SSH). Again, you haven't provided any information about EXACTLY what you did. Which directory did you switch to? You can run "git status" from any directory within the workspace; by default it shows the status of the entire workspace. I don't know what you mean by "specify some files for the new branch". A branch starts at the same commit where the branch was created, so you have all the same content on the branch as you had before you created the branch. Until you change something of course. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why does git tell me a gif file needs merge - how would you ever merge a gif file
What did you do during these 2 days of learning? Did you start one of the excellent books on Git, such as the Pro Git book referred to earlier: https://git-scm.com/book/en/v2 and go through it step by step? Or did you just randomly read man pages etc. and type commands? I highly recommend the former. The latter will not be successful, unless you're already very familiar with SCM tools in general and distributed SCM tools in particular. Another advantage to going through a book like this is it will give you the terminology you need to ask questions in ways that we can understand. Many of the questions we see from users take much longer to solve because the questioner is using incorrect terms, so there's a lot of back and forth between us trying to work out exactly what they're asking. Finally, when asking for help please provide EXACT commands you typed and EXACT error messages/results you received. You can modify things to be more private (for example you can change the hostname of your server to "my.host.com" or something like that) but having the exact commands is critical to determining errors. On Tue, 2017-04-04 at 05:25 -0700, bestbrightestandthens...@gmail.com wrote: > 1. I'm in the path ../bitbucket/source (remote repo) You should absolutely, positively NOT be in the "remote repo" when you make a clone! In Git you are in the location where you want to create the clone, and you provide the clone command the name of the remote repository you want to clone. > 2. I did the command: git clone with a path So, you access the remote repository via a path, not over SSH or HTTPS or some other protocol? > 3. It replies Cloning into 'whatever' ... > 4. It replies Checking out files: 100% (6140/6140), done > 5. I then went to path /bitbucket/sourcecode (localhost repo) > 6. Entered the command: checkout -b branch1 > 7. This replies back (many files) needs merge Suppose your repo is available to you via a path like "/remote/repo.git" and your home directory is something like "/home/me". Then I suggest you create your clone like this: cd /home/me git clone /remote/repo.git It will choose a default name of the repo for you, or you can provide one specifically if you prefer: git clone /remote/repo.git repo Now you can change to your clone of the repo: cd /home/me/repo and see all your files. If you run "git status" you should see you have no modified files. Now to make a new branch such as "my/branch1" you would run: git checkout -b my/branch1 "git status" should again show that you have no files modified. Now if you change a file and run "git status", it will show that file as modified. If you can get this far, then you should be back on track. If there are specific problems please ask them by providing the exact command and exact output using cut and paste, not paraphrased abstract commands. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Re: No available terminals
On Mon, 2016-12-19 at 06:07 -0800, Dexx Mandele wrote: > This is the right place to report git issues, right? Because at the moment > git is forcing me to restart several times a day to circumvent this problem. > A fix, a work-around, or even some basic pointers would be greatly > appreciated. This list is read by Git users, not Git maintainers (well, probably some maintainers are here) and allows more experienced users to help directly. It's not the right place to report issues to the Git maintainers. In your case in particular you're using Windows, which many readers of this list are probably not using themselves, or at least not constantly for in-depth work. I assume you're using the Git for Windows port of Git; since your problem is extremely Windows-specific you might have more luck asking for help from them directly. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git binary download link. RHEL 7.2. Can't do yum.
On Tue, 2016-12-06 at 12:54 -0800, sam.mahm...@symago.com wrote: > I need Git binary download link from credible source. If Red Hat's official RHEL repositories aren't OK, then how can anything we suggest here on a random mailing list be considered "credible"? That's an ill-defined term... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Yet more git madness
On Tue, 2016-11-01 at 15:36 -0700, AD S wrote: > Sorry, I meant pull request. Everyone else's code (2,800+ files and > 250+ commits) are suddenly in the pull request I was working on (which > had 8 files and 4 commits). As mentioned this seems more a rant about GitHub and its development model than about Git per se (although of course GitHub simply codifies a particular style of working with Git). Most of my uses of Git are more traditional "hub and spoke" model, with one central Git repository that all the developers use as their sole upstream, via personal branches. It's quite straightforward to work with. Layering a multi-repo, multi-upstream process on top of that does increase the complexity, and potential for errors, significantly I expect. It's important to be able to visualize what's going on internally here so you can determine what the right action is and what the result will be. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Yet more git madness
On Mon, 2016-10-31 at 18:42 -0700, AD S wrote: > So I was working on a branch that had a total of 8 files. I needed to > make adjustments to 3 of those files. I pulled, made the changes and > pushed. Went to check on the branch on Git Hub and all of a sudden > everyone else's commits are on my branch. Over 2,800 files and 250+ > commits. I hate to step in here because usually messages like this are just exercises in publicly venting frustration, rather than actual requests for assistance. However I don't quite understand what you mean, above. Every single branch in Git represents a history from the HEAD of the branch (where the branch tag points) back to the beginning of the repository. So, when you say "everyone else's commits are on my branch" it's not clear what what that refers to, but if you mean that you are seeing all the commits back to the start of the repo, not just the commits "on your branch", then that's expected: that's how it works. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else
On Sat, 2016-08-27 at 10:07 -0700, Michael wrote:
> if someone forked my repository, did work on "master", and submitted
> it to go onto my "master", then how do I say "No, come in on a branch
> named devB instead"?
Something important to understand is that your local repository and
every remote you register all have their own "namespaces" for branches.
Because of this, in fact someone else's "master" can never interfere
with your "master" or a different remote's "master".
The default name for the remote you cloned from is "origin". That means
there's an "origin/master", "origin/foo", "origin/bar", etc. for every
branch ("master", "foo", "bar") that exists on the remote. So you can
see what the remote's master contained with "git log origin/master" (as
of the last time you fetched from that remote). You can compare them
with "git diff origin/foo foo", etc.
You also have your own branches, "master", "foo", "baz", etc. which are
local to your repository and don't exist in the remote.
And if you add a second remote (which of course has to have its own
name, not "origin") then you will get all of its branches imported into
your repository, but under that remote's name, so "other/master",
"other/foo", "other/boz".
So there's really no reason to be concerned about other people using
"master", since that's their "master" and is not your "master". They
are in different namespaces and Git won't get them confused.
However, people soon discovered that _much_ of the time, you really only
have a single remote and the extra command line fu needed to keep
everything straight was annoyingly redundant. So Git has a concept of a
"tracking branch", which is a local branch which is tracking a branch in
one of your remotes. If your local branch is a tracking branch for some
remote's branch, then when you pull from that remote Git knows to merge
from that remote's branch into your branch.
Note there's no reason at all that the remote branch and the local
tracking branch have to have the same root name. A local branch "foo"
could be tracking a remote "other/fubar". So, you could have a local
branch "master" which tracks "origin/master" and a different local
branch "master_other" which tracks "other/master".
You might try reading
https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches which I
think explains this fairly well.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git-new-workdir, and updating local workdir
On Mon, 2015-11-09 at 10:01 +, Phillip Lord wrote: > Now I pull to "~/src/my-repo" so it updates > say master (or feature-branch). In ~/src/my-repo-branch/master running > git log will show the latest commits to master, but the working > directory will be out of date. Konstantin gives you excellent details. However, I follow a simple rule which lets me avoid these concerns: I never pull in the "real" repo (in your example, I never pull in "~/src/my-repo"). In fact, I never use that repo directly at all: I don't even cd to it. You can/should just pull in your workdirs. As long as all your workdir copies of the "real" repo are using different branches, and you don't mess around with the contents of the "real" repo yourself, you won't have any issues with new-workdir. Of course when you're delivering code (for example, into master) then you need to check out master in one of your workdirs which breaks the above rules. I personally only ever use new-workdir for personal branches, so I never make a new-workdir that is set to master. I merge back one of my personal branches in its workdir back to master, then I *delete* that workdir (if I'm done) or set it back to the personal branch or check out a new personal branch. I never let a workdir sit with "master" checked out. If you do need to have "master" checked out in more than one workdir then Konstantin's instructions on how to manage it are spot-on. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Looking for a change to a file
On Sun, 2015-09-13 at 11:32 -0700, Michael wrote: > I've got a file, with a diff/change, that I thought had already been > checked into a previous commit. I want to see if this change exists in > any checkin of that file. > > Is there any way to ask for "all the checked-in versions of file X"? > As far as I know, git only knows files by their sha hashes, and not by > names -- which already tells me that there's probably something that I > really don't understand about git. Git doesn't know files by SHA hashes. Git knows "a set of changes to one or more files" by its SHA hash. The SHA hash names the _commit_ not a specific file. However, if you want to see the commits that impacted a given file it's trivial: git log If you want to see the commits that impacted any file in a subdirectory that's trivial as well: git log -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] bare repository checkout
On Thu, 2015-07-23 at 06:43 -0700, dexter ietf wrote: git clone with --bare option was significantly faster, so i just assumed it fetches the bare-minimum data. thanks for your detailed answer, it all makes sense now. The difference in time tells you how long it takes to extract a working tree from your Git repository :) -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git doesn't detect change, if file modification time is restored to original one
On Thu, 2015-07-23 at 01:23 -0700, Konrád Lőrinczi wrote: I should somehow ignore atime and mtime when doing diff for status. Just to be clear, what this would involve is for every file in the repo, Git would have to extract the HEAD version into a temporary file (or memory buffer) then compare it to what's currently in the work tree. I'm not saying that such a thing should be impossible; adding some kind of flag that does this sort of 100% reliable check could be useful. But, it's not surprising that no one would want to use such a flag (and hence why it's not implemented now). Of course, you could write a script that would do this yourself, and explicitly git add any file determined to be changed. I wonder if it wouldn't be simpler to just modify the tool you're using so it doesn't reset the timestamp on the file in the first place... -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Could not load program git
On Wed, 2015-07-22 at 07:41 -0500, John McKown wrote: I wonder what it is. I thought that it was git the SCM because the source link pointed to the GNU ftp server and the git directory within it. Git-the-SCM is not a GNU project and not available from the GNU ftp server. You found GNU Interactive Tools (GIT) which has been around for a long time (longer than Git-the-SCM) but was not very well known. See: http://www.gnu.org/software/git/ However due to the popularity of Git-the-SCM, GNU Interactive Tools was renamed gnuit in 2007 or so: http://www.gnu.org/software/gnuit/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Merging between multiple git svn repositories without the svn
On Mon, 2015-07-20 at 14:47 -0500, John McKown wrote: I am not a git internals person. But I think you may have a misunderstanding. git doesn't use a dependency graph to do merges. ... The second is a non fast forward merge (SHA-1 commit value is not in the list of commits in the remote). This is what you are experiencing. In this case the desktop repository has changes which are not in the remote repository. What git does, in effect, is compares each file (contents) in your working directory with the equivalently named file (contents) in the remote repository. Actually Git can and does use a dependency graph for merging, as all reasonable SCM tools do. Your algorithm is correct as far as it goes, but you're missing a crucial step: when Git determines there's no fast-forward merge it uses the dependency graph to come up with the most recent common ancestor commit, then it does a three-way merge between your local version and the remote version with the most recent common ancestor as the base version. Using a three-way merge GREATLY improves the accuracy of the basic merge algorithm, because if one of the new versions matches the ancestor and the other one doesn't, Git can assume that it should automatically choose the unmatched version since that's the change. Only if neither new version matches the base version do you have a conflict. See, for example, the git merge-base command which will show the relevant common ancestors. However, obviously this doesn't help if you're trying to merge two different repositories, since Git can't compute common ancestors without walking the parent commit tree. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: On Thu, Aug 21, 2014 at 10:16:08PM -0400, Paul Smith wrote: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? Well, reading the man page for `git clean` like a lawyer (my emphasis below): -X Remove only *files* ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. I set up a small example that I hope matches your situation: Yes, that's it. So git doesn't want to delete the ignored *folders* Debug/ and Release/. Even more interestingly is the behaviour when we start ignoring '*.o' too: My take on this is that git clean is doing a top-down operation, and when it comes across a file that is not in .gitignore (SOMELIB.dir) it stops and doesn't go down any further. For git status on the other hand, it DOES continue to go into SOMELIB.dir and then due to .gitignore it ends up pruning out everything inside that directory, then it doesn't print the empty directory (since git status never shows empty directories). I would argue that raising a bug on this is called for. OK thanks for the analysis! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Fri, 2014-08-22 at 21:05 +0200, Magnus Therning wrote: On Fri, Aug 22, 2014 at 07:41:46AM -0400, Paul Smith wrote: On Fri, 2014-08-22 at 10:05 +0200, Magnus Therning wrote: So, it could be argued it does what it says, it removes all *files* ignored by git, not ignored *folders*. Yes, but that's what the -d option is for. You'll note that the -x option has similar language regarding files. No, not quite, this is from the man page again: -d Remove untracked directories in addition to untracked files. So, again when reading it as a lawyer, the folder is not untracked, it's ignored. The behaviour of `git clean -dX` when hitting an ignored folder is therefore unspecified. Hm. I think the wording in the man page is incorrect or at least too loose. It's not possible in Git to ever have a tracked directory; Git doesn't store directories per se. A directory comes into existence only because there's a tracked file in it. So, untracked directories is, at the level of lawyer-ese anyway, meaningless. However we can assume that they mean to say directories which contain no tracked files here. Which would give the behavior I want. I think. :-). As is the experience of every C programmer, unspecified stuff is a source of much trouble. So I'd say that's another reason to raising a bug ;) I've found some threads on the git mailing list from 2010 and 2012 about this issue. It doesn't seem like consensus was reached. I'm going to construct a followup for that list and try to push it forward. Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git clean vs git status re .gitignore
On Wed, 2014-08-20 at 06:50 +0200, Magnus Therning wrote: Is there a specific reason you aren't using a separate build directory? (AFAIU this is the convention for CMake.) Historical precedence. People are used to doing in-source builds and some of our scripting for making releases, etc. expects to find things in those places. I completely agree that it would be great to move to an out-of-source build as the default but that's a larger project. In any event, this question is more abstract, summed up by this: Does it seem incorrect to anyone else that git clean -X doesn't delete all the files in your workspace that are considered ignored by git status? How does `git clean -fdx` behave? It does clean up these files... plus more as below. I've never really understood the difference between -x and -X, but I've always used only -x and it behaves exactly the way I expect it to. According to the docs (and this seems true to me), -X removes all files matched by .gitignore (except, in my case, not) while -x removes all ignored files AND all untracked files [*]. The thing about -x is you could lose work; if you had a new file that you hadn't gotten around to git add'ing, or you had a log file that you still wanted to look at but wasn't matched by a .gitignore line, etc. then -x will delete it while -X does not. The -X flag only deletes things that you've explicitly marked (via .gitignore) as ignorable, but leaves things it isn't sure about (untracked files) alone. [*] Technically what it does is pretend there's no .gitignore file, so that all ignored files become untracked, then delete all untracked files. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git 2.0
On Tue, 2014-07-01 at 15:35 -0500, Joanna Wilkinson wrote: I get this error in the terminal: fatal: repository '[your-repository.git]' does not exist You missed the first item in Konstantin's reply: I mean, what exact action you carry out with Git Without knowing what command you typed there's little we can say. Based on the above error it looks like you entered an incorrect command. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git 2.0
On Tue, 2014-07-01 at 16:15 -0500, Joanna Wilkinson wrote: I'm sorry, this is my first time using this. I am just following the instructions seen here: http://developers.squarespace.com/using-git/ I typed in: git clone [your-repository.git] And I get this error: fatal: repository '[your-repository.git]' does not exist You are not supposed to type the literal string [your-repository.git] You are supposed to replace that string with the address (URL) of your Git repository. From the document you're following: To clone your template, log into your Squarespace site and go to the Developer tab. Under SFTP details there will be a line that says “Repository.” Copy the URL listed there. You should use the URL you copy from that site in place of the string [your-repository.git]. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Re: git reset with staged changes
On Wed, 2014-06-04 at 11:23 +0200, Pierre-François CLEMENT wrote: Beware, though. I don't have my Git reference to hand, but I've noted that if the file is in the index, it is tracked [...] Really? Sounds a bit strange. I feel like tracked files are committed files, and that staged files are about-to-be-tracked files I'm no expert on Git but I think you're looking at it wrong. What's below is my understanding: A tracked file is a file that Git knows about. An untracked file is a file Git doesn't know about. More concretely, any file that has ever been git add'd is tracked. Files that have never been git add'd are not tracked. That means files that are committed and unmodified, files that are staged (whether they've previously been committed or not), and files that have been committed or staged and are now modified are all tracked files. Given these states a file can be in: 1. committed 2. staged change to a previous committed file 3. modified version of previously committed file 4. staged new file that's never been committed 5. untracked file The first four are tracked. I think git reset --hard currently does the right thing for the first 3--it's defined to throw away modifications (#3) and people WANT it to do that much of the time, so there's no way that behavior could be changed IMO. Possibly it could save the modifications to backup files, or require a force option and without it suggest you stash modified files, or whatever. You may have an argument about #4. I personally think it would be reasonable to have git reset --hard turn staged files that are new back into untracked files, rather than just deleting them. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Re: git reset with staged changes
On Wed, 2014-06-04 at 10:28 -0400, Dale R. Worley wrote: From: Paul Smith p...@mad-scientist.net A tracked file is a file that Git knows about. An untracked file is a file Git doesn't know about. More concretely, any file that has ever been git add'd is tracked. Files that have never been git add'd are not tracked. That's not true either. If in one commit a file was added, and in the next commit, it was deleted, then *now* it is untracked (even though it was once added). There are a million special case situations and it's too exhausting for both the author and the reader to be sure to cover all of them every time, which is why you perceive ambiguities in the documentation. Also, this can be considered a matter of definition. Another way to look at it is that the file in that directory now has never been git add'd because it's a different file, as the one before was deleted. If you delete a file foo from your directory then create a new file foo, is it the same file? Or a different file? If a cat named Felix is sitting in a box then you take it out and put in another cat also named Felix, is the cat in the box the same cat or a different cat? What if the two cats are clones? And, how can you use Git to answer these questions? :-). Anyway, the only trivially correct answer is that if you run git status and it reports the file is untracked, then it's untracked. If it reports the file is in any other state, then it's tracked. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Setting log message with git merge --squash... ?!?!
So, it appears to be impossible to set or change the log message in any way when doing git merge --squash. I've tried all of these, at least: * --log * --no-log * --log=0 * -m foo No matter what options I provide the squash merge commit message always appears as the standard computed message, completely unchanged. The only solution I've found is go whack the .git/SQUASH_MSG file directly after the merge command completes!! Is this really right? It seems ridiculous to me that I cannot control that message from the command line. Why is the --squash version of the merge command so anemic in this respect compared to a normal merge command? I'm using Git 1.8.5.3; maybe this is improved in a newer version? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] How to find out (fast) if a commit is on a _specific_ branch
I need to write a hook that will allow merge commits ONLY if the merge is coming from a specific branch. I know about git branch --contains but that checks ALL the branches to see if the commit is on any them, and with the number of branches we have that takes a non-trivial amount of time. Since this is in a push hook I really need it to be as fast as possible, and it seems to me that if I could ask for just a specific branch, is this commit on this specific branch rather than what are all the branches this commit is on, it would be faster. But I can't quite find a good way to do that. I mean, I can list the entire history of the branch then search it by hand, but that seems inefficient as well. Is there some plumbing command or similar that will check if a specific commit exists a specific branch, fast? Thanks! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] .gitignore isn't ignoring.
On Fri, 2014-04-18 at 12:49 -0700, gordonle...@gmail.com wrote: I've set intellij to ignore the three build files, but it too doesn't appear to be ignoring it. .gitignore only impacts file which are untracked (that you've never added or committed). You can't ignore files that you've already told git are interesting to you, even if you later add them to .gitignore. Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: build.number modified: build.properties modified: build.xml This means someone already committed these files to the repository, and you've now modified them. They cannot be ignored. If they were added to the repository by mistake (usually it's wrong to add these kinds of build products to the repository, but different groups do it different ways) then you have to run git rm ... to remove them from your current version of the repository. Then if they're recreated, .gitignore will start ignoring them. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] what does **/ pattern mean in git?
On Apr 18, 2014 7:17 PM, gordonle...@gmail.com wrote: Hi, what does **/ pattern mean? Why couldn't the person used doc/*.txt instead of the below? Doc/*.txt matches files ending in .txt in the doc directory while doc/**.txt matches files ending in .txt in doc or any subdirectory of doc. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] cherry-pick strangeness... or bugs?
I'm using Git 1.8.5.3 on GNU/Linux. I need to backport a discrete set of commits to an older release branch. Because this is an older branch I definitely do not want to merge: I need to either rebase or cherry-pick or whatever. Rebase doesn't seem to be an option, because the set of commits aren't on their own branch and rebase doesn't appear to allow specifying a specific list of commits to rebase. I could use rebase -i, but the branches have diverged so far that there are hundreds of commits I'd have to skip just to the the 8 or so I want to keep. Too annoying. So I was going to use cherry-pick but ran into two problems: The first one is that I wanted to cherry-pick a range, plus a straggler, so I did this which appears from the man page to be what I want (obviously my real command uses SHAs): git cherry-pick A^..F J The intent is to skip commits G, H, and I. However, this does not work; it attempts to cherry pick ALL the commits in the range A..J, including G, H, and I. Is this a bug in Git, or am I misunderstanding something? So then I decided to list the commots one at a time on the command line rather than use the range. These commits are all a flailing attempt to fix a problem (unfortunately in order to get these changes into our test system they had to be pushed so this flailing is now public *sigh*) so I thought I would like to use the -n flag with cherry-pick to do a kind of merge --squash and combine all the flailing into one commit. However, the very first cherry-pick had a conflict I needed to resolve, so I did resolve it. Normally one would then git add and git cherry-pick --continue but doing so with -n gives an error: error: Your local changes would be overwritten by cherry-pick. hint: Commit your changes or stash them to proceed. fatal: cherry-pick failed If I try NOT git adding the change before running --continue then I get: error: Your local changes to the following files would be overwritten by merge: foo/bar.cpp Please, commit your changes or stash them before you can merge. Aborting So, am I missing something or is git cherry-pick -n just not usable in any situation where you might have a conflict that needs to be resolved? I'm going to create a temporary branch and run the cherry-pick there (without -n), then do a merge --squash, which I expect will work. But I wonder if the above are bugs I should report, or misunderstandings on my part, or simply expecting too much of the tool. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] starting out with git -- a problem with branching....
On Tue, 2013-09-03 at 08:05 -0700, maya melnick wrote: but I imagine in other situations, to have to commit every time before switching branches is weird... what if you haven't finished work on a branch and need to switch branches to take care of another problem, but don't want to commit what you just did because, well, you're not ready to commit? ;-) That's what the git stash command is for. Check it out! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Question: git merge origin/master
Hi all. This is just a simple question. Most of the discussions of merge from master to my branch I've seen recommend this: git checkout master git pull git checkout mybranch git merge master I did things this way at first, but as I understood git more it seemed to me that far simpler, and completely equivalent (with the exception that the master branch is not updated, which is fine) would be: git fetch git merge origin/master Is there some downside to this alternative that I'm not seeing, or other consideration (philosophical or otherwise) that should be taken? Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Question: git merge origin/master
On Thu, 2013-06-13 at 19:30 +0400, Konstantin Khomoutov wrote: On Thu, 13 Jun 2013 11:00:42 -0400 Paul Smith p...@mad-scientist.net wrote: Hi all. This is just a simple question. Most of the discussions of merge from master to my branch I've seen recommend this: git checkout master git pull git checkout mybranch git merge master I did things this way at first, but as I understood git more it seemed to me that far simpler, and completely equivalent (with the exception that the master branch is not updated, which is fine) would be: git fetch git merge origin/master Is there some downside to this alternative that I'm not seeing, or other consideration (philosophical or otherwise) that should be taken? If you have a local branch named master which is set to track origin/master, the second sequence won't update it because `git pull` in the first sequence does fetching *and* then merging of what was fetched into the currently checked out branch -- master. Yes, sure, that's why I said above with the exception that the master branch is not updated. That doesn't matter to me at this point because I just want my branch updated. Later on, when I want to merge my branch back to master, of course I would update master first then merge from my branch, then finally push to origin. Remember I'm trying to reproduce the result in the first sequence above, the goal of which is to merge from the upstream master branch into my work branch. Note that you might as well be *not* interesting in having such a local master branch at all! Possibly but that's not the question above. In our environment we are required to merge our own branches to master in our own repo, then push the result to the upstream git server. So I do need a local master branch which tracks origin/master. The question above is talking only about intermediate merge steps, where I want to bring in other peoples' changes into my work branch before I merge back to master. I'm just wondering if there's some issue with merging directly from origin/master, rather than first updating my local master and merging from that. I can't see one. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git rebase for cleanup, after pushing
On Sun, 2013-06-02 at 08:32 -0700, Sam Roberts wrote: If the tests run before the merge into master, then the normal procedure is that after you know the branch tests pass, you rebase your-feature to clean it up, and do a push -f to overwrite it. Then people comment, maybe you rewrite again based on their comments. Only when everybody is happy does it merge to master. At that point you can't rewrite. Since nobody should be doing work based on your feature branch, it doesn't matter how often you rebase it. Yes, sorry, I made a mistake near the end of my email when I wrote However, I've already pushed my branch to master. That should have read However, I've already pushed my branch to the server Git repository. In short, I have to push my personal branch to the main Git repo when it's still a work in progress, and so others will get it in their repos when they do a git pull. My question was, what's the best way to clean up before merging those changes to the master branch. It looks like, as long as I can reasonably expect that others have not checked out my branch I can rewrite my branch using rebase -i and that's OK. I'm still looking for a powerful, but easy-to-use interface to git rebase -i. I'm using Magit (Emacs mode) and it's ok, but something that makes it simpler to slice and dice commits down to the patch chunk level while hiding the details of using stash/pop, etc. would be SO amazing. I envision something like, on the left a list of commits, and on the right a window with diffs. You can rearrange/modify commit messages/delete the commits in the left window, and when you select a commit you can see the patch chunks for that commit. You can drag by file and/or by chunk from into another commit. The ability to even edit a given patch/chunk would be even more cool. Safety features such as being able to show a diff between the tree before the rebase and after all the rebase steps were complete, would be ideal. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git rebase for cleanup, after pushing
On Thu, 2013-05-30 at 22:29 -0700, PJ Weisberg wrote: On May 30, 2013 6:32 PM, Paul Smith p...@mad-scientist.net However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely? I don't understand why you don't do all this cleanup *before* you merge into master. I DO want to do the cleanup before merging to master. If you mean do the cleanup before pushing to the git repo, I can't do it all because it's not until after I push that I can detect build issues on platforms I don't have access to, get feedback in a code review, etc. Sometimes it's useful to keep these changes as separate commits, but often it's not. There's no problem with rebasing published history per se, only with rebasing history that someone else might have pulled into their own history. You can rebase to your heart's content as long as you're on your own branch, even of it does have to live on a remote server. Certainly others will have pulled the branch: it's in the master repo after all. I guess it's unlikely they'll have checked out my dev branch though, typically. Also, it's not quite so simple: our server has gitolite installed and push -f to force move a branch has been disabled. I guess I can do it in two steps: first delete the branch then add it again. Lastly, I've played with rebase -i. It's powerful, but not quite what I was hoping for. I wonder if anyone has any pointers for something like: You start a rebase --diff (or whatever) operation. It shows each diff that is part of the branch, and allows you to assign that diff (or just an individual chunk of the diff) to a particular commit, or delete the diff or chunk. It walks through each chunk of each diff like this. At the end any commit with no chunks assigned will be deleted, and the branch will be rebased using the remaining commits. Comment editing, etc. would need to be possible. Since you're actually just looking at chunks in the diff between the first commit and last commit, and not any intermediate commits, I don't think it's possible to get a conflict (although you obviously could get intermediate commits which don't build, if you're not careful, making git bisect somewhat tricky). For some kinds of commits, where there are ordered incremental (overlapping) changes that you wanted to preserve this wouldn't work. But if you have a set of non-overlapping changes to different areas needed to make a change or set of changes, it might be a good way to handle rebase. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Git rebase for cleanup, after pushing
Hi all. I run across this problem quite a bit: I have a branch that I'm working on. Unfortunately for me, in order to get my code tested and built by our build servers and infrastructure (which is a requirement before it can be code reviewed and merged, plus it builds my code on platforms I don't otherwise have easy access to) I have to push it to our main git repo, since that's the only place the build infrastructure can get it from. This means I have to publish my work-in-progress branches up to the git server, including all the false starts, backups, single-line oops fixes, etc. Then if I merge my branch into the master branch, all that becomes part of the mainline of the code. If it's a small change which is really just one thing I can just use a squash merge into master. But for larger changes what I'd like to do is clean it all up into a smaller set of well-formed commits and push those. This sounds like a job for rebase -i. However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely? Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Can't Git Config my ID
On Tue, 2013-04-30 at 08:59 -0700, catherine.segu...@gmail.com wrote: I try to get started. Thank you wery much! It is the message pop up when I commit : The error message tells you how to fix the problem (Run ... git config ... etc.) It's unfortunate that the Git GUI doesn't appear to have a GUI interface to the configuration settings, so you'll have to use the Git shell and run those commands. This page may be of assistance: http://www.dalsoft.co.uk/blog/index.php/2011/08/30/getting-started-with-git-on-windows/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git apply doesn't add new files...?
On Thu, 2013-03-28 at 16:43 -0400, Dale R. Worley wrote: If you think about it, in many situations git commit -a is what a software developer wants to use. Various trash files can accumulate in a working copy; you usually only want to commit files that have been specially pointed out as being valuable. Sure. I'm not in any way saying git commit -a is doing the wrong thing or should be modified...? I'm talking about the behavior of git apply. I don't really see many situations where you want to apply a patch and have all the modifications and deletes be processed but not the adds. As an example of the kind of problem this creates, if I have a workspace with some untracked files in it and then I run git apply, I now have no way to tell which files were created as part of the git apply and should be added to my commit with git add, and which were there before and should not be added. You really, really shouldn't use git apply unless the working copy is clean. (Unless you want to combine the changes that git apply makes with all the changes that are already present to make one commit.) I agree with you if by working copy is clean you mean there are no modifications to Git-controlled files... that would be a problem. And in my case there are none. I don't agree if by clean you mean that I should be deleting the various trash files that can accumulate in a working copy; these files may be important even though they shouldn't be added to Git. Since they're not known by Git, stash doesn't help. It is a real PITA to move them outside of the repository while dealing with patches, then move them back. I don't want to require everyone to do that just to apply patches. The risk that some added file in the patch will overlap with a local file already in my workspace is very small, and if it happens then the patch will simply fail to apply. Anyway, git apply --index, while not quite what I wanted, is working OK for me. Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git apply doesn't add new files...?
On Thu, 2013-03-28 at 10:22 -0400, Dale R. Worley wrote: When apply is done and I run git status -s, the files that were specified as deleted in the diff are marked as D but the files that were specified as added in the diff are marked as ?? (untracked), not A as I'd expected. Running git commit then will commit the deletes but the added files continue to be untracked, not added (of course). OK, I'm not familiar with git status -s. I suggest that you do git status instead and read the output carefully. The -s flag just prints a shorthand version of the output. Using -s vs. not -s does not change the results. With -s the output is simpler to read carefully :-). According to my understanding, git status should report that some files have been changed, some deleted, and some added, but it should report that *none* of these changes have been staged. Well, what do you mean by report that some files have been added? What's the status you'd expect to see for those files? I would expect to see them listed prefixed with new file:. But in fact they're listed in the untracked files section. And if you do git commit, it will object that nothing has changed. I'm running git commit -a, which commits all the files that Git knows about. This commits the modified and deleted files. Since these new files are untracked, or not known to Git, they are not committed. If I go and run git add newFile.h for one of the untracked new files, now it shows up in git status output as a new file in the Changes to be committed section, and git commit -a will add it as expected. In regard to the files that were specified as added in the diff are marked as ?? (untracked), that is completely correct -- the files haven't beed added to the index and are not present in the head commit, so they aren't tracked. (A file is tracked if it is in the base commit of the repository or if it is in the index. -- from my writeup of the basics of Git.) Maybe I should restate. The problem is that if I run git apply followed by git commit -a, the files that were modified and deleted are both committed, but new files from the patch are not committed. I sort of understand it from a Git point of view, since unlike modified or deleted files there's no way to have a state of added but not staged in Git. Nevertheless, to me this is an unexpected difference in behavior between change/delete/add files in git apply. As an example of the kind of problem this creates, if I have a workspace with some untracked files in it and then I run git apply, I now have no way to tell which files were created as part of the git apply and should be added to my commit with git add, and which were there before and should not be added. However, I'll work around this by using the --index flag; I can always un-stage afterwards if I need to. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reformatting vs. git blame
On Tue, 2013-03-26 at 22:30 +, Philip Oakley wrote: From: Paul Smith p...@mad-scientist.net Sent: Tuesday, March 26, 2013 9:11 PM On Tue, 2013-03-26 at 20:46 +, Philip Oakley wrote: We accept that git blame across the reformat will not be useful. I'm going to lay down a label right before the reformat, so people can use that to trace back git blame before it happened. I also will use a special code reformat user ID for the reformat commit, The key point here is that this script should be able to record the corrected tree as though it is a simple 'commit --amend' so that the 'User' can either be your special code reformat user, or it can be the developer. Hi Philip; I really appreciate your assistance. Unfortunately I've yet to need to delve into some of the more advanced features of Git. I've used commit --amend of course, but I'm having a bit of trouble putting everything together based on your comments. The key is to ensure the script can be applied as a `git filter-branch`, and that it can maintain the developer's user name. Thus every commit on the developer's branch will be reformatted by the developer, so that: a) they can rebase their branch to match your desired start point and b) when their branch is merged it will slot in nicely I've read the man page on filter-branch and it seems to be somewhat applicable. But I don't quite see how it all fits together. For example I can see that I can use filter-branch to go through a list of commits and apply my reformatter to each one. But I'm not sure how that solves the authoring problem: doesn't that still show the first commit (where the first reformat was performed) as all modified by the current user? I can see that I can change the user by modifying the environment inside the script, but that would (from what I see) make ALL the changes in the commit, including the diffs, authored by the reformatter user account. The process I was considering for each non-master my/branch was: 1. Check out my/branch 2. Merge up to the master commit just before the reformat 3. Reformat the code on my/branch (don't commit) 4. Generate a patch from the master commit just after the reformat 5. Throw away the local reformatting changes from step 3 6. Reset my/branch to the master commit just after the reformat 7. Apply the patch 8. Commit to my/branch 9. Proceed with development as normal This is like a squashed merge and I lose the commit history for the branch, so there are downsides. Also as before, how best to accomplish step #6 is not clear to me. But it appears to maintain the git blame results I'm hoping for and avoids massive changes in blame as these reformat straddling branches are merged back. Can you give something like the above level of detail for the process you suggest using filter-branch? It doesn't have to be exhaustive: I can easily handle the scripting once I understand the process. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reformatting vs. git blame
On Wed, 2013-03-27 at 11:30 -0400, Dale R. Worley wrote: I do not see why merging a branch in will cause all lines in the file to be marked as changed by the user who did the merge (from whose branch the merge was done). Assuming the reformatting in the master and the reformatting in the developer's branch is exactly the same, when the developer goes to merge his changes back into master, only lines that he changed for real will be different -- lines that were changed only by reformatting will be changed in exactly the same way in both sources, and presumably git blame does not consider them to be changed by the merge. Ah. Interesting. Maybe my problem is I stopped part-way through and extrapolated incorrectly. Looking at the _branch_ I see everything is modified by the developer. But you're saying if I merge back to master then the changes already on master will be preferred and all those lines will be blamed on the reformat user, just as I hoped. That sounds reasonable. Let me try that. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reformatting vs. git blame
On Wed, 2013-03-27 at 13:51 -0400, Dale R. Worley wrote: But it suggests that if the same change was made in multiple ancestor commits, git-blame might be picking out the commit with the latest modification time. I can see an argument to be made for both models of handling multiple commits with the same change: choosing either the newest (who changed it last) or the oldest (who changed it first--assuming later changes were just copies of the earlier ones). In any event, it seems the simple solution isn't going to help me unfortunately :-(. Thanks. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] git apply doesn't add new files...?
So, I have a patch that was created with git diff (can't use format-patch in my situation). If the patch deletes files, such as: diff --git a/foo.cpp b/foo.cpp deleted file mode 100644 index ccfb3ce..000 --- a/foo.cpp +++ /dev/null @@ -1,82 +0,0 @@ - ... then those deletes are reflected in Git after the git apply, which is good. But, if my patch ADDS a file, such as: diff --git a/bar.h b/bar.h new file mode 100644 index 000..46ecebe --- /dev/null +++ b/bar.h @@ -0,0 +1,40 @@ + ... then this file is just left in my workspace as an untracked file, and not added with git add. This is annoying. Is there a way to convince git apply to add new files to Git? Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git apply doesn't add new files...?
On Wed, 2013-03-27 at 17:48 -0400, Dale R. Worley wrote: From: Paul Smith p...@mad-scientist.net So, I have a patch that was created with git diff (can't use format-patch in my situation). If the patch deletes files, such as: then those deletes are reflected in Git after the git apply, which is good. But, if my patch ADDS a file, such as: then this file is just left in my workspace as an untracked file, and not added with git add. This is annoying. What do you mean those deletes are reflected in Git? According to the manual page, the file should be deleted in the working directory, but it won't be removed from the index. Similarly in the second case, the file should be added in the working directory, but it won't be added to the index. Sorry, I was unclear. No, I didn't use --index as I wanted to see the applied content before it was committed. I ran git diff -M -C master to generate the patch of changes between my working directory and the master branch, then ran git apply (no arguments) in another workspace to apply it. When apply is done and I run git status -s, the files that were specified as deleted in the diff are marked as D but the files that were specified as added in the diff are marked as ?? (untracked), not A as I'd expected. Running git commit then will commit the deletes but the added files continue to be untracked, not added (of course). -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Reformatting vs. git blame
Hi all; please don't respond just don't do that, because that's not an option :-). We are reformatting our codebase. Obviously we want to do this exactly one time, and be done. I have an automated tool that will perform this reformatting, which includes not just whitespace / indentation but also adding braces and similar changes, so just ignoring whitespace is not sufficient. I can script this so that it will redo the entire codebase with one command, and the result is stable / reproducible. We accept that git blame across the reformat will not be useful. I'm going to lay down a label right before the reformat, so people can use that to trace back git blame before it happened. I also will use a special code reformat user ID for the reformat commit, so that it's obvious in git blame when lines were changed due to the reformat, vs. being changed afterwards. That's all fine. My issue is how to handle unmerged developer branches, without breaking my git blame results. Having developers reformat their branches works and gives an easy merge post-reformat, which is nice, but it also blows away the git blame results: basically every branch merged in will look like that user changed the entire tree. That's not so good. Reformatting only the files that were modified on the branch is a little better but still leaves the entirety of each modified file marked as modified by a given user due to the reformatting, even if only one line was changed. Also not ideal. What I really need is somehow to re-apply the changes from a branch on top of the post-reformatted version, with only the actual changes involved being noted as new, not the reformatting. However rebase won't cut it because I need to apply the reformatting to the changes as well, to avoid massive conflicts. Maybe something like this: 1. For each modified file on the branch: * Reformat it * Generate a diff between that version and the post-reformat master version and save it as a patch file * Get rid of the local reformat 2. Merge from master, forcing it to keep theirs so our branch is now the same as master. 3. Apply the patches from step 1. This _should_ be clean/no conflicts. 4. Commit. 5. Continue working merging, and when done merge back to master. Would that work? Am I missing something? An easier way? I'm not sure how to accomplish step #2. I note that while git merge has a -s ours, there's no -s theirs which seems to be what I want. I could reset the branch to the post-reformat tag then apply the patch, but that is not a merge commit so there's a break in the history. I don't know if this is significant or not. Suggestions on how to accomplish the goal, and things to think about, are appreciated! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reformatting vs. git blame
On Tue, 2013-03-26 at 20:46 +, Philip Oakley wrote: We accept that git blame across the reformat will not be useful. I'm going to lay down a label right before the reformat, so people can use that to trace back git blame before it happened. I also will use a special code reformat user ID for the reformat commit, Is this user ID programmable? (see later) I'm not sure what you mean; isn't it possible for pretty much anyone to declare a given author on commit? So, yes, if I understand the question. What I really need is somehow to re-apply the changes from a branch on top of the post-reformatted version, with only the actual changes involved being noted as new, not the reformatting. However rebase won't cut it because I need to apply the reformatting to the changes as well, to avoid massive conflicts. After updating your master with you script, get developer to update their own branch, but as a filter-branch, with their own username. They now have a corrected data set that can be rebased, or a format-patch set generated, that summarises their changes which should be apply-able upstream. This would work, I think, but then wouldn't it attribute all the changes in their branch to the reformat user as well, in addition to the reformatting? Maybe that's OK, or at least better than having each user appear to reformat the majority of the code on each merge (for any outstanding branches) I presume you want any work-in-progress branch to be based on top of your newly reformatted master! Yes, that's the goal... the question is how to get there. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Reset branch to master after merge
I've been searching but I've not found anyone else asking about this. In my workflow I tend to do a bunch of work on a topic branch, merge it to master, then do some other things and come back a few weeks later and pick it up again. Obviously when I start working on it again I want to start with the current master HEAD, not with the content that existed on the branch prior to my merge to master: master now contains all the code from my topic branch, plus all the new code people have added, already merged and ready to go. Certainly I can merge again from master back to my topic branch, but this creates a new commit on my topic branch for the merge. This seems unnecessary to me. I believe I'd prefer to reset my branch to master after I merge it, so that when I merge from master it does a fast-forward, until I decide to start working and make changes on the branch. Does this make sense? How do other people handle this situation? Do people just do the merge and accept the extra commit? We have a number of developers making lots of changes and our git repo is REALLY complicated (I can rarely make any sense out of gitk etc. as there are so many branches all over the place). This model seems to add to that confusion (for me). Or do people delete their topic branch after the merge and re-create it later? I've tried a git reset --hard master and that works for my local branch, but I've had trouble figuring out how to deal with the remote branches (I need to push my local branches to our main repo so it can undergo code review etc. before merging to master). Thoughts about this situation are welcome; Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Reset branch to master after merge
On Mon, 2013-03-11 at 10:54 -0500, Ryan Hodson wrote: 1) Use the topic branch as a short-lived branch that just serves as an isolated environment for you to do some work on a particular feature. This means you would delete it as soon as you merge it into master, because that feature is done, at least for the time being. When you want to start work on it again, create a new topic branch for it, and repeat. 2) Use the topic branch as a long-running feature branch. If you were to do this, you should *not* merge it into master until it's completely done. This means the topic branch would co-exist with the master branch as long as you're still working on it. If you need to pull in updates from master, then you would either a) rebase the topic branch onto master or b) merge master into the topic branch (but *not* the other way around). I do #2... I work and merge from master periodically, then when I'm ready to deliver I merge my topic branch back to master and I'm off doing other things. But then after a while I often pick back up the branch to implement further features etc. It's this last bit that seems outside the norm... but I do it fairly often. So your opinion is that it's better to delete the branch after I merge, then recreate it later, rather than trying to force it to point to the master post-merge commit so I can ff-merge it later? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
