On Tuesday, February 28, 2017 at 9:52:11 PM UTC+1, Philip Oakley wrote:
> On Tuesday, February 28, 2017 at 5:28:14 AM UTC+1, AD S wrote:
>
>> The statement that git will have problems is untrue, as long as it is the
>> same file/filename in the same place/path.
>
>
Your changes to it will (should) merge in just fine.
I've been told it is not a good idea to create the same file again as Git
> will see them as 2 different files with the same name and won't necessarily
> merge them together.
Philip, am I correct to assume that the future merge "correctness" would
actually also depend on where in the history graph we are at the moment of
doing the proposed checkout of the file from a different branch...? I
quoted the "correctness" because once the merge happens, the result would
certainly be correct technically, but possibly unexpected (thus perceived
as "incorrect", actually just something that was not wanted).
For example:
(*1*) ---A---B---C master
\
X---Y---Z topic1
In this case, if we`re currently on "master" branch and we do 'git checkout
topic1 -- file.txt', where "file.txt" doesn`t yet exist in "master",
depending on what we do with the file, once "topic1" gets merged to
"master" the result may be surprising (both branches adding the same file,
but with a bit different content) -- if we just add contents to the file,
it should all be fine, but if any of the branches remove anything from the
file before they get merged, the removal might be reverted and removed
content could reappear in the merge commit, which might be both unwanted
and unexpected (example (2) below, commits 1, 2 and 3 are changes to the
new file we checked-out from "topic1").
(*2*) ---A---B---C---1---2---3---M master
\ /
X---Y---Z-----------/ topic1
Thus, could it be better to follow "natural flow" of the history instead,
and incorporate changes in place where they feel most "natural" -- checking
out a non-existent file from a different branch in order to modify it and
commit the changes separately from the branch the file was created in might
not be the best idea, especially if you`re new to Git...?
So, would it be a good suggestion to follow the history and apply the
changes where they (arguably) "belong" -- on the branch containing the file
we want to modify:
(*3*) ---A---B---C master
\
X---Y---Z topic1
\
1---2---3 topic2
Now, there is no more problem of a non-existent file -- we`re on branch
"topic1" and we create/checkout a new branch "topic2" there, modifying the
existing file as needed (commits 1, 2 and 3 again).
Once "topic1" gets merged into "master", we can merge "topic2" as well, but
this time we can rest assured that no matter the changes we did in those
commits 1 to 3 (adding, changing or removing content), the upcoming merge
will yield expected results (file state from commit 3 coming out as a
"winner", being expected as it is the latest file state). We would finally
have a situation like this:
(*4*) ---A---B---C---M1 master
\ /
X---Y---Z topic1
\
1---2---3 topic2
(*5*) ---A---B---C---M1---------M2 master
\ / /
X---Y---Z topic1 /
\ /
1---2---3 topic2
What do you think?
Of course, in a scenario like this, we could skip merging branch "topic1"
(we could delete it altogether as well) and just merge "topic2", but due to
a specific workflow that may not be desirable (like a pending review / pull
request for a specific task/issue we were working on in "topic1", being
separate from "topic2", where we would like to keep the two logically
separated and shown inside the history as such).
And as a side note, if we`re fine with rebasing, once we have the case
shown in (4), instead of doing merge (5), we may rebase "topic2" onto
"master" (M1) to get even cleaner history before issuing a pull request, if
that`s what we prefer. With a merge commit M2 in the end it may look
something like this ("topic1" text omitted to spare some space, but it`s
still at commit Z as in previous examples):
(*6*) ---A---B---C---M1------------M2 master
\ / \ /
X---Y---Z 1'---2'---3' topic2
... but this may be now pretty much falling out of the scope of the initial
question, though just saying, all the possibilities :)
Regards,
Buga
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
