2

Now before anyone says this is duplicated it is not.
Everyone else is asking as a person committing.

In my case, I have to have a program commit certain lines of some files.

I would rather not use git add -p and then have to parse output and do command line interaction via a program.

Is there a way to just give a list of line numbers when making a commit?

I know it has be done programmatically at least once because GitHub does it.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
dtracers
  • 1,534
  • 3
  • 17
  • 37
  • Your script should first create the new file based on old file + new lines (and information as to where they should be inserted). Then commit the new file. I would use bash for this. I don't think it's a git one-liner... – Martin G Jul 18 '14 at 06:08
  • I am planning on writing this in python. So basically I should save the old file with all lines, (either using git or writing it out) overwrite this file with only the new lines I'm wanting to commit (plus any old lines from previous commits) commit that code, then restore the file in its entirety? – dtracers Jul 18 '14 at 06:10
  • What changes are you trying to commit? Are you deleting or adding lines? Can you express the edit as, say, a `sed` script? – CB Bailey Jul 18 '14 at 06:11
  • I have never heard of an sed script before! that is actually really interesting. But I am not sure how well that will mesh because these line numbers are given through a python server. And I have to be able to handle modifications, additions, and deletions. As this is metadata for the actual individual commit but can affect metadata for previous commits – dtracers Jul 18 '14 at 06:18
  • As a side note about your implementation: for portability I'd recommend the tools which are found in "git bash" prompt of the usual Windows *git* installation. So, *bash*, *sed*, *awk*, or just do it all with *perl*... Then you can just take your script to any Windows host with *git* installed and it "should" work. – hyde Jul 18 '14 at 06:25
  • well actually I am using this GitPython library to help some abstraction and some other parts of the server have to be in python. But I will look into using perl for this as that might work out well too. – dtracers Jul 18 '14 at 06:36
  • Do you have any _staged_ changes that you want to avoid committing or is it OK to use the default index? – CB Bailey Jul 18 '14 at 06:57
  • I do not think I have to worry about that. It should only be unstaged commits and possibly untracked files. – dtracers Jul 18 '14 at 07:00
  • So what format do you receive this list of line numbers in? Is it simply a list of lines to choose from the working copy instead of the committed revision? Are the selected lines contiguous or in multiple batches of consecutive lines? – CB Bailey Jul 18 '14 at 07:02
  • I am not sure as that has not been specified yet It will be from the working copy though. It will honestly be something very similar to how github handles selecting multiple lines so they might be multiple batches of consecutive lines – dtracers Jul 18 '14 at 07:05
  • I think that you need to get that specified, then. The hard part of this isn't the git operations, it's producing the input programmatically that is some lines from one file and some lines from another file unless the input is well defined and unambiguous such as int the format of `ed` commands. – CB Bailey Jul 18 '14 at 07:09

1 Answers1

0

As illustrated in vim-fugitive issue 237 and shown in the video "Git Merge • Gapply.vim (Andrew Radev), June 2013", you could use git apply instead of git add -p.

The idea is to edit the diff, save it as a patch, and apply it.
That does work well in vim, because vim will update the hunk markers (start and end line numbers) according to your modification.

But since you will change the diff non-interactively, you might need to use rediff in order to update the patch, before applying it.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250