0

What is the recommended and easiest way to get some local code to be the new head of a repository? That includes

  • no merging required, just use the version of the local code
  • files which are not present at local code shouldn't be in the repository either

The result should be quite similar to initializing a new repository with the current local code, while keeping the information of past checkins.

user236012
  • 265
  • 1
  • 2
  • 9

3 Answers3

1

You have made two contradictory specifications:

  • files which are not present at local code shouldn't be in the repository
  • while keeping the information of past checkins

So, the current local code consists of files "one.txt" and "two.txt".

The past checkins consist of "one.txt", "two.txt", "red.fish", and "blue.fish".

Requirement #1 says that "red.fish" cannot be in the repository.

Requirement #2 says that "red.fish" must be in the repository.

Please pick some new requirements. I suspect your first one is where the problem is, but it's important that you realize what you're asking for, otherwise the result won't make sense.

torek
  • 448,244
  • 59
  • 642
  • 775
  • The result should be that one.txt and two.txt are present at master, while red.fish and blue.fish should have been marked as 'deleted' when committing the local code. – user236012 Jan 09 '17 at 02:17
  • Then, as jdow said, just `git add -A` and commit. This will violate requirement #1 (the two other files will remain in the *repository*, they just won't be in the new snapshot) but apparently that was an incorrect requirement: you want the current work-tree to be taken as "the set of all files that should go in the next commit", which is what `git add -A` does. – torek Jan 09 '17 at 02:22
  • @user236012 I don't understand then...why that title? For a git user feels like you want to change master (since you say that you do not initialize a repository...) – fedepad Jan 09 '17 at 02:29
0

git add -A followed by git commit, should do what you want. provided you are on branch master.

This assumes that when you say "keep the information of past check-ins" you want to keep the commit history.

jdow
  • 316
  • 2
  • 9
0

I think there are some misunderstandings here.
When you are working in your computer, you're working basically with your 'local version of the code' and you have different branches, one of which might be called 'master'. Of course can be synchronized to a remote or not.
@torek has very good points!
Probably what you want to do is to create or have a local branch with the code and then somehow treat it as the new master, but I'm just inferring since it's not clear at all from the question.

From your question my intuition tells me that you are hitting the following use case:
Make the current git branch a master branch
but again, going a little bit out on a limbo here.

Community
  • 1
  • 1
fedepad
  • 4,509
  • 1
  • 13
  • 27
  • yes, it might be a bit unclear. let me explain it in other words: the goal is to set the current status of the local code as some kind of new startig point for further developments. there are quite a few changes/deletions/adds, and in order to not need to go through the merging process manually, I just want to say "take this code, and merge that to the current master such that when somebody pulls the master, he will end up with exactly the same status as here." – user236012 Jan 09 '17 at 02:32
  • @user236012: `git pull` *means* "merge". If you don't *mean* merge, don't use `git pull`. However, the point of working with branches within version-control systems is, usually, to be able to merge. – torek Jan 09 '17 at 02:39
  • I agree with @torek! – fedepad Jan 09 '17 at 02:40