[git-users] Re: Git rebase proposal: Should rebase preserve commit dates as it rewrites, I vote yes

[Igor Djordjevic]

Hi Eric,

On Thursday, August 16, 2018 at 5:22:38 PM UTC+2, Eric Newton wrote:
>
> I propose default rebase operation should preserve either the commit 
> date/author date so that I can legitimately use the git commit log as a 
> backup to my timesheet.  A squashed commit clearly loses its dates, but the 
> rebase operation should preserve commit date/author date.
>

Default `rebase` behavior preserves author date already - does that work 
for you?

Otherwise, you can use `--committer-date-is-author-date`[1] 

 
option to set (keep) committer date to that same author date, too.

You could also make an alias so you don`t have to type it all out each time 
you need it.

What do others think?
>

As author and committer dates serve different purposes, I think the current 
defaults are just fine, while additional options do allow fine-tuning where 
different behavior is needed. But that is only my opinion, of course :)

Still, might be `config` option would be nice, like 
`rebase.commiterDateIsAuthorDate`, or something, but that would be a topic 
for main Git mailing list[2] , as Tim already 
suggested. List archives can be found at public-inbox[3] 
.

Regards, Buga

[1] 
https://git-scm.com/docs/git-rebase#git-rebase---committer-date-is-author-date
[2] g...@vger.kernel.org
[3] https://public-inbox.org/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.

[git-users] Re: Gitignore strage behaviour of !

[Igor Djordjevic]

Hi Sahib,

On Sunday, February 18, 2018 at 1:18:55 AM UTC+1, Sahib Bin Mahboob wrote:
>
>
> I was playing with this following gitignore for fun:
>
> */**
>
> *!/app*
> *!/app/a*
>
>  
> And later tried with this command "git check-ignore app/a -v" with the 
> output:
>
> .gitignore:7:!/app/a app/a
>
>
> As per as I understood from Gitignore doc 
>  "*!/app/a*" should indicate to 
> include "app/a" more precisely but instead git is ignoring it.
>
>
> Any idea what I am missing here?
>

Are you saying (for example) `git status -uall` doesn`t show "app/a" for 
you anymore, or you`re just confused by its output (or one from `git 
check-ignore -v app/a`)? Mentioning your Git version might be good as well.

I`ve tested your case with version 2.16.1.windows.1, and it seems to work 
as expected (and described by the docs).

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Fetching part of a repository

[Igor Djordjevic]

Hi Michael,

On top of what Philip already mentioned about shallow clone (in case you 
don`t need history), you can also use "sparse checkout"[1] 
 for the case you 
don`t need all the files, either. An example:

git clone --no-checkout --depth 1 https://github.com/gnustep/gap.git
cd gap
git config core.sparseCheckout true
echo "user-apps/FlexiSheet/*" >> .git/info/sparse-checkout
git checkout


Note that you still *do have *all the files inside ".git" folder, just not 
checked out... One of the core Git philosophies is that project repository 
contains everything, and you get (to work with) everything, being a major 
drawback in working with huge repositories - but there`s work in progress 
in that regards, which is what Philip also addresses in second part of his 
message :)

Regards, Buga

[1] https://git-scm.com/docs/git-read-tree#_sparse_checkout

On Tuesday, December 19, 2017 at 12:25:14 AM UTC+1, Michael Gersten wrote:
>
> Is there a way to get a partial repository, such as 
> https://github.com/gnustep/gap/tree/master/user-apps/FlexiSheet 
>
> without getting every app there? 
> --- 
> Entertaining minecraft videos 
> http://YouTube.com/keybounce 
>
>

-- 
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] Re: git commit --amend -F option help

[Igor Djordjevic]

Hi praveenm,

On Friday, December 8, 2017 at 8:02:48 AM UTC+1, praveenm mulimani wrote:
>
> Dear All,
>
> We are using git commit -F option to commit in git.
>
> when we use git commit --amend option with -F it is creating new gerrit 
> permalink.
> ex: git commit --amend -F /opt/commitmessage.txt
>
> How to amend the commit msg without creating new permalink.
>
> Let me know if  other options are available.
>
> Thanks in Advance
>

Would this be a "Gerrit" related/specific question, instead of a "Git" 
one...? If so, might be "Gerrit" mailing list is a better place for it -- 
https://groups.google.com/forum/#!forum/repo-discuss?

On the "Git" side, executing `git commit --amend -F /opt/commitmessage.txt` 
should just amend the commit using provided text file as commit message 
(replacing the previous one), not sure where the permalink part comes from 
(if not "Gerrit)".

Otherwise, hopefully someone here has more experience with this setup to 
help further.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: worktree with orphan

[Igor Djordjevic]

Hi Philip,

On Friday, December 8, 2017 at 7:43:45 PM UTC+1, Phillip Lord wrote:
> 
> I'm trying to create a new worktree, but for an orphan branch. But I 
> can't find a way of doing this convieniently. 
> 
> I can checkout a new orphan branch: 
> 
> git checkout --orphan my-new-branch 
> 
> That works, but now I can't make a worktree because, I presume there 
> are no commits yet. 
> 
> fatal: invalid reference: another-new-branch

Indeed, worktree should point to something inside repository, and 
currently you have nothing - even your "my-new-branch" doesn`t really 
exist yet (as being orphaned it has no history), unless you commit 
something to it, as you noticed.

Doing `git branch` confirms this, no "my-new-branch" listed.

> More over, it leaves any files on master in place. 

Hmm, not sure what you remark to here, but if it is about leaving 
index and working tree in the same state as where you left off (I 
guess "master", in your case), that is by design, and it can be 
easily cleaned-up with `git rm -rf .`, if desired (see `git-checkout  

--orphan` docs[1] 
 
for more info).

> ... But, okay, I think, I can move back to master.
> 
> git checkout master 
> git worktree add ../my-new-branch my-new-branch 
> 
> But this fails for the same reason. 
> 
> git worktree  add ../my-new-branch my-new-branch 
> fatal: invalid reference: my-new-branch 

As your orphaned branch never really started existing in the first 
place (no commits on it), once you moved back to "master", you lost 
any track of it, and Git still (rightfully) complains about it 
missing just the same.

> So, the only solution is 
> 
> git checkout --orphan my-new-branch 
> 
> git commit (something) 
> 
> git checkout master 
> git worktree add ../my-new-branch my-new-branch 
> 
> All of which seems pretty painful. 
> 
> Am I missing something? 

On top of everything said above, I may suggest a possibly more 
satisfying alternative:

git worktree add --detach ../my-new-branch

We can inspect the current worktree state:

$ git worktree list
/test-repo   273bf25 [master]
/my-new-branch   273bf25 (detached HEAD)

Now, you can go to that worktree and do this:

git checkout --orphan my-new-branch

Inspecting the situation again, we get this:

$ git worktree list
/test-repo   273bf25 [master]
/my-new-branch   000 [my-new-branch]


Do note that "my-new-branch" still doesn`t really exist until the 
first commit is made there (as explained at the beginning of this 
e-mail), but might be you find this flow a bit more convenient...?

Regards, Buga

[1] https://git-scm.com/docs/git-checkout#git-checkout---orphanltnewbranchgt

-- 
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] Re: Conflict occurs with different file names.

[Igor Djordjevic]

On Thursday, November 9, 2017 at 10:06:50 PM UTC+1, Igor Djordjevic wrote:
>
> ... Git has "rename detection", where if one file is missing on one side, 
> but another file appeared one the other side - having different names but 
> (even just almost) the same content, Git will see that as a rename, and act 
> accordingly, possibly trying to merge two files, as you experienced.
>

Wording might be a bit unfortunate here, as I initially wanted to write 
something else - could be this is more understandable:

Git has "rename detection", where if one file is deleted, but another file 
appears - having different names but (even just almost) the same content, 
Git will see that as a rename, and act accordingly, possibly later trying 
to merge two files, as you experienced.

-- 
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] Conflict occurs with different file names.

[Igor Djordjevic]

Hi Philip,

On Thursday, November 9, 2017 at 9:29:52 PM UTC+1, Philip Oakley wrote:
>
> I think what you are seeing is that you you have confused different parts 
> of the display messages.
>  
> I believe Git says:
>  
> You asked Git to cherry pick a commit that has the subject line 
> "dir02/abc.apk"
>

At first I thought the same, but I managed to actually recreate the issue, 
and the warning line really mentions (different) file name at the end. In 
my test example, it was: 

warning: Cannot merge binary files: a.txt.gz (HEAD:a.txt.gz vs. c8fe548... 
testing:b.txt.gz)


... where "testing" is a commit message, and "b.txt.gz" the actual filename 
in that commit (opposing "a.txt.gz" inside HEAD).

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Conflict occurs with different file names.

[Igor Djordjevic]

Hi,

On Thursday, November 9, 2017 at 9:42:06 AM UTC+1, euni...@gmail.com wrote:
>
> Could a conflict occur even though the file names are different?
>

Yes.

dir01/test.apk and dir02/abc.apk have different names. Why is there a 
> conflict?
>

What Philip already mentioned - Git has "rename detection", where if one 
file is missing on one side, but another file appeared one the other side - 
having different names but (even just almost) the same content, Git will 
see that as a rename, and act accordingly, possibly trying to merge two 
files, as you experienced.

Git says - you modified file "dir01/test.apk", other side renamed file 
"dir01/test.apk" to "dir02/abc.apk" and modified it, too -- thus Git still 
seeing it as the same file and trying to merge, and failing as these are 
binary files. Other side might have actually deleted "dir01/test.apk" and 
created new "dir02/abc.apk" which just happened to be almost the same as 
previously deleted "dir01/test.apk", Git will still see that a simple 
rename of the old file (plus the modification).

Note that if other side`s file, "dir02/abc.apk", wasn`t modified but 
_exactly the same_ as previous "dir01/test.apk" file (regarding file 
content), your "dir01/test.apk" file would have just been renamed to 
"dir02/abc.apk" as a direct consequence of the cherry-pick you attempted -- 
as even if not actually, contextually that`s exactly what happened on the 
other side :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: tell git diff to ignore lines that were moved, but not changed

[Igor Djordjevic]

Hi Richard,

Maybe not exactly what you`re looking for, but "Git" v2.15.0 introduced 
"--color-moved"[1] 
 option 
for "git diff"[2] . For a quick example, 
you could use it like this:

git -c color.diff.newMoved=white -c color.diff.oldMoved=white diff 
--color-moved

... where you can specify color of your diff context/unchanged lines in 
case they`re not white. You may also try with "--color-moved=plain" and see 
which one works better for you (default is "zebra", see documentation for 
more details).

This will still show you +/- inside diff for moved lines as well, but only 
changed/added/deleted lines will actually be colored, making them clearly 
stand out (moved lines appearing as context lines, if you set the same 
context color as explained above).

Regards,
Buga

[1] https://git-scm.com/docs/git-diff#git-diff---color-movedltmodegt
[2] https://git-scm.com/docs/git-diff

On Tuesday, November 7, 2017 at 1:12:46 AM UTC+1, Richard Dooling wrote:
>
> Hello,
>
> I use git to track changes to large book-length text files, so I am 
> constantly moving lines, blocks of lines, even whole chapters around. 
>
> It would be quite nice if I could do git diff and see only lines that were 
> either changed, added, or deleted, but not the lines that were simply moved 
> to another location in the file.
>
> I suspect a filter script is what I needed and I'm hoping maybe somebody 
> has one?
>
> Thank you for any help.
>
> Rick Dooling
>

-- 
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] Re: How to see ALL my commits? Including from any branches I've made.

[Igor Djordjevic]

Hi PeteR

*"git log"*[1]  was a good thought, you 
just need to add "--all" parameter, as by default only current branch is 
logged, as you noticed, arguably being the most common use case.

What helped me in the beginning was remembering - "What everyone needs? *A 
dog*!"[2]  :), that is:

git log --*a*ll --*d*ecorate --*o*neline --*g*raph


Might be irrelevant for now, but you should also know that in some cases 
Git might still decide not to show all the commits -- this is being 
considered a feature, and part of *"history simplification"*[3] 
, being helpful 
with understanding complex history graphs. To ask Git not to simplify 
history, parameters "--sparse" and "--full-history" are used... but it 
should be safe not to bother with this in the beginning -- or most of the 
time, even :)

[1] https://git-scm.com/docs/git-log
[2] https://stackoverflow.com/a/35075021
[3] https://git-scm.com/docs/git-log#_history_simplification

Regards,
Buga

On Friday, November 3, 2017 at 9:55:39 PM UTC+1, pro...@ucsd.edu wrote:
>
> All I want is a complete list of the SHAs and tags of all the commits 
> I’ve made, including those on any branches  (obviously I’m a  beginner and 
> have some wrong concepts). 
>
>
> I don’t see how from the documentation. I want to see the commits from 
> branches as well. 
> I tried "git show —max-parents=0”  — gave me nothing, while "git show" 
> gave me far too much detail but not the commits from the main line of 
> commits (i’m on a branch).
> I thought that “git log” would show all my commits, but it only shows the 
> commits of the branch I’m on.
>
> PeterR
>

-- 
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] Re: How to remove a directory from the index?

[Igor Djordjevic]

Hi PeterR,

In short, "git submodule" is one git repository (submodule) inside another 
git repository (superproject). For more info you may check "7.11 Git Tools 
- Submodules" , 
gitsubmodules[7]  and 
git-submodule[1] .

Do you have any ".git" file or folder inside your "ModelCtrl" directory?

What does "git status" output?

Regards,
Buga

On Sunday, October 29, 2017 at 9:32:00 PM UTC+1, pro...@ucsd.edu wrote:
>
>
> By mistake I did “git add my_directory”, without adding any files in the 
> directory.
>
> When I tried git-adding a file in the directory,, git complains it’s a 
> fatal error:
>
> fatal: Pathspec 'modelside/ModelCtrl/Main2.c' is in submodule 
> 'modelside/ModelCtrl'
> In this message, “ModelCtrl” is the directory in question, and Main2.c is 
> a file to be added.
>
> How can I remove "my_directory" from the index? And add the files in the 
> directory to the index? 
> What is a submodule ?  
>
> Thanks for any advice..
>
> PeterR
>

-- 
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] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Unfortunately, the graphs are too long and complicated for some more 
serious eyeballing, but important point should be _there are_ graphs, 
meaning both "branchA" and "branchB" contain commit 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc... but that we already knew, I`m 
afraid.

So, it does seem like both these commands` output is unexpected:

(*1*) $ git log --format=%H --sparse --full-history branchA..branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
(*2*) $ git log --left-right branchA...branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

... where they both find the commit in question, case (2) showing it as 
belonging to "branchB". At least these two seem to be in some agreement 
between themselves :P

I`m getting out of ideas :/ You could try adding "-m" parameter to the mix 
(if that makes any sense), or removing "--sparse", and seeing if anything 
different comes up. Ideally, it would be good to get a (much) shorter 
history with the same behavior which could be examined more easily, but 
yeah...

I`m talking from the top of my head, but maybe a script which will walk 
"branchA" history and do "two dot" range specification with each commit in 
"branchB" history, searching for cases which yield commits which still 
appear in both "branchA" and "branchB" history (so something fishy is 
happening with "log" function, like with sample commit 9ba8f06829 above), 
and finally checking the distance of these "false positive" commits  from 
"branchA" and "branchB" commits used inside "two dot" range specification.

The shorter the distance, the better the commit candidates are for 
examination.

Or/and, you could try bringing this question up on the main *Git mailing 
list* <g...@vger.kernel.org>[1], might be it`s something obvious for people 
much more involved with Git internals :)

[1] g...@vger.kernel.org

Regards,
Buga

On Wednesday, August 9, 2017 at 12:48:28 AM UTC+2, Chris Murphy wrote:
>
> Here it is:
>
> https://gist.github.com/cmurphycode/6a134f8d383d08b024be6c17dda23891
>
> https://gist.github.com/cmurphycode/31a6bd4eafaa9f6e32f7fa465a27ec6d
>
> On Tuesday, August 8, 2017 at 5:50:40 PM UTC-4, Igor Djordjevic wrote:
>>
>> Hmm... For what it`s worth, another two to try out (note addition of 
>> "--ancestry-path"):
>>
>> (*1*) git log --graph --format=%h --sparse --full-history 
>> --ancestry-path 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchA
>>
>> (*2*) git log --graph --format=%h --sparse --full-history 
>> --ancestry-path 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchB
>>
>> Hopefully, these two can show a bit simpler graphs of how 
>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc eventually gets in both "branchA" 
>> and "branchB".
>>
>> On Tuesday, August 8, 2017 at 10:12:21 PM UTC+2, Chris Murphy wrote:
>>>
>>> Definitely:
>>>
>>> - branches made from branchA which are merged into branchA
>>> - branchA has been merged into branchB at least once
>>>
>>> and probably:
>>> branches made from branchA which are merged into branchB
>>>
>>> Here's the result of the commands - doesn't seem like they affected the 
>>> doubledot result:
>>>
>>>
>>> ± % git log --format=%H --sparse --full-history branchA..branchB | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % git log --format=%H --sparse --full-history branchA | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % git log --format=%H --sparse --full-history branchB | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % shasum <(git log --format=%H branchA..branchB) <(git log --format=%H 
>>> --sparse --full-history branchA..branchB)
>>> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/11
>>> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/12
>>>
>>>
>>> I did some long-shot exploring as well. I thought it might be 
>>> interesting to try to narrow down when this problem "happened". 
>>>
>>> ± % git log branchA --oneline | head -1100 | while read id junk; do git 
>>> log $id..branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc || echo 
>>> $id; done | grep -v commit
>>> d257212899
>>> 07c8974cbf
>>> 8c9dac3f13
>>> 190772b842
>>> 33ae1d39bd
>>> 4ff39884f6
>>> 283e0c60

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hmm... For what it`s worth, another two to try out (note addition of 
"--ancestry-path"):

(*1*) git log --graph --format=%h --sparse --full-history --ancestry-path 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchA

(*2*) git log --graph --format=%h --sparse --full-history --ancestry-path 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchB

Hopefully, these two can show a bit simpler graphs of how 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc eventually gets in both "branchA" 
and "branchB".

On Tuesday, August 8, 2017 at 10:12:21 PM UTC+2, Chris Murphy wrote:
>
> Definitely:
>
> - branches made from branchA which are merged into branchA
> - branchA has been merged into branchB at least once
>
> and probably:
> branches made from branchA which are merged into branchB
>
> Here's the result of the commands - doesn't seem like they affected the 
> doubledot result:
>
>
> ± % git log --format=%H --sparse --full-history branchA..branchB | grep 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>
> ± % git log --format=%H --sparse --full-history branchA | grep 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>
> ± % git log --format=%H --sparse --full-history branchB | grep 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>
> ± % shasum <(git log --format=%H branchA..branchB) <(git log --format=%H 
> --sparse --full-history branchA..branchB)
> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/11
> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/12
>
>
> I did some long-shot exploring as well. I thought it might be interesting 
> to try to narrow down when this problem "happened". 
>
> ± % git log branchA --oneline | head -1100 | while read id junk; do git 
> log $id..branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc || echo 
> $id; done | grep -v commit
> d257212899
> 07c8974cbf
> 8c9dac3f13
> 190772b842
> 33ae1d39bd
> 4ff39884f6
> 283e0c6056
>
> Essentially, if you walk down the git log for branchA, you get all "false 
> positives" until d257212899 which is "correct". (And after 283e0c6056, the 
> next several hundred are correct as well)
>
> That makes 1a6035b06eebbeed6ce2ea4bf3058360f261f8fa the "last" (according 
> to git log order) false positive. 
> Was hoping that closer look at that commit will help, but haven't found 
> anything yet.
>
>
> On Tuesday, August 8, 2017 at 3:54:16 PM UTC-4, Igor Djordjevic wrote:
>>
>> On Tuesday, August 8, 2017 at 2:38:09 PM UTC+2, Chris Murphy wrote:
>>>
>>> You're right, I didn't mean to leave the --tags=1 in. I double checked 
>>> that the --tags and greps didn't remove any lines from the output.
>>>
>>> However, I did overlook the carat syntax - on zsh, those need to be 
>>> escaped. I repeated this with escapes and also double-checked against bash 
>>> just in case. I think this is what you wanted:
>>>
>>> https://gist.github.com/cmurphycode/5df15669ce1e5c33f3e69d997b465d6d
>>>
>>
>> This one looks interesting, as we can see both 03dd551f03 (merge base) 
>> and 9ba8f06829 (your initial "surprising" commit) in there. By the looks of 
>> that graph only, it seems clear that 9ba8f06829 does not belong to 
>> "branchA" (its graph ending with merge base commit) -- but, that may be 
>> true considering "branchA", "branchB" and the merge base commit 
>> 03dd551f03 _only_.
>>
>> Do you have other branches in your repository, where some of them 
>> are/were merged to/with these two branches we`re looking at? If so, that 
>> might explain the situation further.
>>
>> But even if not, I`m thinking if Git`s *"history simplification"* 
>> <https://git-scm.com/docs/git-log#_history_simplification>[1] could be 
>> the the culprit here...? Could you try your initial commands again, but 
>> adding "--sparse" and "--full-history" to them as well? I`m not sure if 
>> there are any other "do not simplify history" switches.
>>
>> So if you could try running something like this (note %h changed to %H as 
>> well):
>>
>> (*1*) $ git log --format=%H --sparse --full-history branchA..branchB | 
>> grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>
>> (*2*) $ git log --format=%H --sparse --full-history branchA | grep 
>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>
>> (*3*) $ git log --format=%H --sparse --full-history branchB | grep 
>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

On Tuesday, August 8, 2017 at 2:38:09 PM UTC+2, Chris Murphy wrote:
>
> You're right, I didn't mean to leave the --tags=1 in. I double checked 
> that the --tags and greps didn't remove any lines from the output.
>
> However, I did overlook the carat syntax - on zsh, those need to be 
> escaped. I repeated this with escapes and also double-checked against bash 
> just in case. I think this is what you wanted:
>
> https://gist.github.com/cmurphycode/5df15669ce1e5c33f3e69d997b465d6d
>

This one looks interesting, as we can see both 03dd551f03 (merge base) and 
9ba8f06829 (your initial "surprising" commit) in there. By the looks of 
that graph only, it seems clear that 9ba8f06829 does not belong to 
"branchA" (its graph ending with merge base commit) -- but, that may be 
true considering "branchA", "branchB" and the merge base commit 
03dd551f03 _only_.

Do you have other branches in your repository, where some of them are/were 
merged to/with these two branches we`re looking at? If so, that might 
explain the situation further.

But even if not, I`m thinking if Git`s *"history simplification"* 
[1] could be the 
the culprit here...? Could you try your initial commands again, but adding 
"--sparse" and "--full-history" to them as well? I`m not sure if there are 
any other "do not simplify history" switches.

So if you could try running something like this (note %h changed to %H as 
well):

(*1*) $ git log --format=%H --sparse --full-history branchA..branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

(*2*) $ git log --format=%H --sparse --full-history branchA | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

(*3*) $ git log --format=%H --sparse --full-history branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc


https://gist.github.com/cmurphycode/114c869323d6d161fd77aa924e769bcd
>
> Here's what the branches point to as of right now, just to be sure :)
>
> ± % git show-ref branchA
> c7770ea9a062d189dc2e3238bdd6f5987d86e1cb refs/heads/branchA
>
> ± % git show-ref branchB
> 944405f8308c77200f7f4cb860a3f95a7a8ba6dd refs/heads/branchB
>
> Thanks for your patience, I appreciate the help!
>

No problem, I`m not sure how much helpful I`ll prove to be in the end, but 
I do find the case interesting, learning something new myself :)

[1] https://git-scm.com/docs/git-log#_history_simplification

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Tuesday, August 8, 2017 at 4:02:43 AM UTC+2, Chris Murphy wrote:
>
> Oh man, sorry, I totally screwed up when editing the output to exclude 
> tags, making the graph totally wrong since some lines were missing. Sorry 
> about that.
>
> I've fixed that issue (Sorry, I still have to edit out tags. I'm 
> using grep -o ".*[0-9a-f]\{10\}\|.* $", and open to any better suggestions)
>
>
> Here's command 1
> git log --tags=1 --format=%h\%d --graph --sparse --full-history branchA 
> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^ | grep -o 
> ".*[0-9a-f]\{10\}\|.* $"
> https://gist.github.com/cmurphycode/84d7efae872a4f23dfb01efdad4836e7
>
> command 2
> git log --format=%h\%d --graph --sparse --full-history branchA branchB 
> ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^ | grep -o ".*[0-9a-f]\{10\}\|.* 
> $"
> https://gist.github.com/cmurphycode/0498a5530e68382d32f1833dfd669311
>

That looks much better, but I`m not sure if it can/should still be trusted, 
either, as "--tags=1" parameter you added can cause (pretty much?) all 
history to still be included, missing the point of last ^{commit}^ 
restriction, and might be grepping could still omit some lines...?

If you would prefer not showing tags, maybe the easiest approach would be 
omitting "decorations" placeholder "%d" inside "--format" parameter 
altogether:

(*1*) $ git log --format=%h --graph --sparse --full-history branchA branchB 
^03dd551f031f48e8702f9154b23f53af8cc4799b^

... and:

(*2*) $ git log --format=%h --graph --sparse --full-history branchA branchB 
^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^

This should produce desired graph history with only commit sha1`s shown, no 
need to grep anything out.

We already know the commits branches A and B point to from your previous 
examples, so missing these should not be a problem -- unless your history 
changed further, in which case you could write these to the right of 
corresponding commits by hand (paying attention not to break the graph 
layout - in case you`re not sure, better just leave it as it is).

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Monday, August 7, 2017 at 9:48:26 PM UTC+2, Chris Murphy wrote:
>
> The gist I uploaded was created via
> git log --format=%h\ %d --graph branchA branchB
>

Is this the _exact_ command you used, or you had some additional grepping 
in there as well (as with your other gists)? Only grepping would seem to 
explain the crippled graph(s), unless I`m missing something else.

Could you try with these commands instead (without any grepping of the 
result):

(*1*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^

... and:

(*2*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
branchB ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^


That should hopefully provide some more info on the state of your 
repository history, both starting from your branch tips and ending (1) at 
the parent commit of the merge-base you discovered, or (2) at the parent of 
the commit you were originally interested in.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Monday, August 7, 2017 at 5:28:15 PM UTC+2, Chris Murphy wrote:
>
> The history of the repo is quite tangled with many merges, but I uploaded 
> it here (with sensitive info removed, sorry, it's a repo for my work) in 
> case it helps:
> https://gist.github.com/cmurphycode/a75d7c4616a93be2bb4fd1096d162714
>

I find the history graph you`ve posted having a bit unusual layout, being 
kind of hard to follow where did it branch, and where merges happened. How 
did you produce it?

For example, for a branching point here:

* | 0abcc19bd9
* | e783d2f321
* 5daf5fedee
* c8cc2f3523


I would expect something like this instead:

* | 0abcc19bd9
* | e783d2f321

|/
* 5daf5fedee
* c8cc2f3523



And here, I guess there are some merges... or not?

| | * ecdbbfcc3c
| | *   951eb3147d
| | * \   f2afcaf2c3
| | * \ \   0d94457c16
| * | | | | 955537dbef
| * | | | |   e59453329b
* | | | | | 03dd551f03



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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: git describe's way of choosing the "most recent" tag

[Igor Djordjevic]

On Sunday, August 6, 2017 at 6:14:24 PM UTC+2, Michael Gersten wrote:
>
>
> On 2017-08-05, at 9:26 PM, G. Sylvie Davies  > wrote:
>
>
> # get most recent annotated tag (by time-of-tagging)
> $ git for-each-ref  --sort='-*committerdate'  refs/tags | head --lines=1
>
> # get most recent lightweight tag (by time-of-commit)
> $ git for-each-ref  --sort='-committerdate'  refs/tags | head --lines=1
>
>
> "for-each-ref"?
>
> Maybe a better question: How is someone supposed to learn all the things 
> that git can do? I've never seen that one mentioned.
>

Mentioned where? Might be by reading *the manual* 
...? 
:) "for-each-ref " is listed 
under so called "plumbing commands".

First reference page entry, git , also 
provides a nice overview of git commands 
.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git branch merge strategies

[Igor Djordjevic]

Hi Mark,

On Thursday, July 27, 2017 at 12:48:25 AM UTC+2, Mark Waite wrote:
>
> Yes, your simplification expresses what I was trying to achieve.
>

Good, then we understood each other, thanks for confirming :)
 

> I specifically merged from master to one so that one could be tested with 
> the merge from master. The subsequent merge from one to master was to have 
> master include a commit which shows one merged into it.  Same pattern for 
> master to two, then two to master.
>

Understandable. I just moved the "subsequent" (the other way around) merges 
to the end (being fast-forward ones), once the three "incremental" (and 
real) merges are done. Might be easier to comprehend like that, otherwise I 
agree with you`re logic.
 

> I assumed (possibly incorrectly) that there would be conflicts to resolve 
> in either merging one or two or both to master.  I assumed that resolving 
> the conflicts would be easier if there were incremental steps which 
> represented the merges.
>
> If there are no conflicts, then isn't the ultimate simplification to merge 
> both 1 and two to master with a single command?
>
>   $ git checkout master
>   $ git merge one two
>
> That will perform an octopus merge and create a merge which has 3 parents, 
> rather than the more common 2 parents.
>

Yes, correct. Even if it`s probably unlikely (or is it?), "no conflict 
octopus merge" scenario is worth mentioning as well, being the 
easiest/simplest one.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git branch merge strategies

[Igor Djordjevic]

Hi JNickVA,

On Wednesday, July 26, 2017 at 8:44:13 PM UTC+2, JNickVA wrote:

> 3. and 4. I don't even have enough information to know the state of the 
> master when each of the 2 branches were created
>

What do you mean here? Isn`t Git history showing you the exact state of 
"master" when each of the branches was branched off...?

I guess we are talking about branches inside the same repository, and not 
more unrelated ones? If so, you should be able to get all the info you need 
from Git itself.

Still, depending on how the commits were made (and how informatively their 
messages are written), it will still be a little hassle -- or a lot of pain 
-- to resolve conflicts inside changes made by other people... :( On the 
positive side, merging some ~40 commits of difference shouldn`t be that 
bad... hopefully :)

-- 
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 branch merge strategies

[Igor Djordjevic]

Hi Mark,

On Tuesday, July 25, 2017 at 2:58:21 PM UTC+2, Mark Waite wrote:
>
> You might consider a series of steps to perform the merge.  Some of the 
> steps might include:
>
>1. Merge from master to branch one so that the diffs between branch 
>one and master are only changes on branch one, test the resulting merge.  
>Review and understand the remaining differences between master and branch 
>one
>2. Merge from master to branch two so that the diffs between branch 
>two and master are only changes on branch two, test the resulting merge.  
>Review and understand the remaining differences between master and branch 
>two
>3. Merge from branch one to master, test the resulting merge.  This 
>resolves branch one into master
>4. Merge from master to branch two, test the resulting merge
>5. Merge from branch two to master, test the resulting merge.  This 
>resolves branch two into master
>
> I`m having some issues following the steps - either I`m missing something, 
or they seem unnecessarily complicated...?

Basically, steps (3) and (5) look like no-operations (fast-forward merges), 
once steps (1) and (4) are done. There should be nothing in there that you 
can test that you haven`t already tested in steps (1) and (4), still you 
propose doing so?

But then again, for steps (1) and (2) you say to merge from "master" to 
branch "one" (or "two"), *"**so that the diffs between branch one and 
master are only changes on branch one"* (or two), and that confuses me the 
most -- what the diff will show should depends on which side of the merge 
you`re looking from, isn`t it?

So if you merge "master" to "one" and you look from "master":

$ git checkout one
$ git merge master
# resolve conflicts, test, add, commit merge
$ git diff master one

..., indeed, the merge commit will show diff as changes introduced only by 
branch "one" - but if you look from perspective of branch "one":

$ git diff one^ one

... diff will show all changes introduced by "master" branch instead (we`re 
actually using the second last commit on branch "one" for comparison, as 
the last one _is_ the merge commit, thus no difference).

By default, if we just show the merge commit on branch "one":

$ git show one

... Git produces a "combined" diff, showing changes in comparison to all 
merge parents (meaning "master" and "one" in the first case), and it 
doesn`t matter which branch you merge into the other, the merge 
outcome/result is the same.

So, unless I`m missing some point, here`re the illustrated steps, for 
easier comprehension. Starting situation would look something like this:

 O one
/
---O---O---O---O---O master
\
 O---O---O---O---O---O---O---O---...---O two

... but to make it easier to follow, I`ll simplify it to this:

 O one
/
---O---O---O master
\
 O two


Now, we proceed with the steps you described:

(*1*) $ git checkout one
$ git merge master
# resolve conflicts, test, add
$ git commit # merge commit M1

 O---M1 one
/   /
---O---O---O master
\
 O two

(*2*) $ git checkout two
$ git merge master
# resolve conflicts, test, add
$ git commit # merge commit M2

 O---M1 one
/   /
---O---O---O master
\   \
 O---M2 two


So far so good, nothing unusual - but here comes the "no operation" part, 
or the "fast-forward" merge in steps (3) and (5) (no work/testing to do):

(*3*) $ git checkout master
$ git merge one
# fast-forward, no merge commit

 O---M1 one, master
/   /
---O---O---O
\   \
 O---M2 two

(*4*) $ git checkout two
$ git merge master
# resolve conflicts, test, add
$ git commit # merge commit M3

 O---M1 one, master
/   / \
---O---O---O   \
\   \   \
 O---M2--M3 two

(*5*) $ git checkout master
$ git merge two
# fast-forward, no merge commit

 O---M1 one
/   / \
---O---O---O   \
\   \   \
 O---M2--M3 two, master


Here, I would only add the final step, making all three branches the same, 
again being a fast-forward merge (thus no changes, no merge commit):

(*6*) $ git checkout one
$ git merge master
# fast-forward, no merge commit

 O---M1
/   / \
---O---O---O   \
\   \   \
 O---M2--M3 two, master, one


All this laid out, I would agree that this could be a good flow to try, 
hoping the diagrams help in following it :) But we could simplify the steps 
a bit, focusing on the three important ones. Starting position again:

 O one
/
---O---O---O master
\
 O two

... and first two steps being the same:

(*1*) $ git checkout one
$ git 

[git-users] Re: Malicious Coder

[Igor Djordjevic]

Hi Lucky Limey,

On Thursday, July 20, 2017 at 4:46:20 PM UTC+2, Lucky Limey wrote:
>
> I have a private repository set up for a project. I may be heading for a 
> dispute with one of the coders How do I protect the repository from 
> vandalism? I would hate for him to delete all our work etc. etc.
>

By removing his write access to the repository? Or just making a clone, or 
a simple copy of it...?

Otherwise, what are you exactly concerned with?

One of the beauties of a distributed version control system, which Git is, 
makes for each repository clone being a full/original/authentic repository 
copy. So as long as at least one person has the repository (locally, or 
wherever), the code and its history can`t get lost/damaged, no matter if 
some repository you`ve declared "central" gets corrupted/deleted/lost - you 
would just clone it again from any other still existing repository.

For example, if I have a GitHub repository, I`ll most probably have a local 
clone of it, the one which I`m working on, so even if my GitHub repository 
gets deleted/detroyed it won`t really matter as I still have everything in 
my local clone, and I can easily recreate GitHub repository as if the issue 
never happened.

Only in case if I`m the only one having the GitHub clone, and I haven`t 
synchronized my local clone lately (through fetch/pull) and there were some 
changes on GitHub side which gets destroyed, I would lose those latest 
commits since my last synchronization, but that`s really the worst case 
scenario - usually more than one person would work on GitHub repo, and any 
of them might have a more recent clone (or s fully up to date one).

Anyway, nothing beats regular/planned backups, just that Git might even 
save you when you (think you) don`t have one :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Git Commit Sequence Issue

[Igor Djordjevic]

Hi Buddhi Nipun Mihara,

On Thursday, July 20, 2017 at 7:55:08 AM UTC+2, Buddhi Nipun Mihara wrote:
>
> I am working on a project which maintains our code base in GitHub. 
> We have faced following issue
> One of our developer changed his local machine date and time. after that, 
> he committed his changes to his fork and then his changes were merged to 
> master branch. 
> After that, I have got a pull request and then did some changes and 
> committed my changes to my fork. 
> but in my fork, my committed are shown below the above-mentioned commit. 
> which has data and time set to August 2017. But I did my changes in July 
> 2017.
>

You described your current situation well, but you didn`t ask any 
questions...? What would you want to do?

No matter the commit date/time, Git won`t get confused about commit order 
in terms of which commit (snapshot, code state) follows the other, and 
commit date/time has no influence there - commit parentage does, where 
parent commits always come before commits they`re parents of.

If commits on different branches have different timestamps, then date/time 
will influence the order in which they`re shown between each other, but 
that doesn`t mean anything other than the obvious, that later commits are 
commited after the former ones - at least as far as their timestamp is 
concerned :)

Also, once your colleague`s commits got merged, if the machine where the 
merge was performed had correct date/time settings, the merge commit 
timestamp should be correct as well, no matter that it actually comes after 
your colleague`s commits with timestamps in the future...

And note that each commit has both "auhor date" and "commit date", though I 
don`t know if that`s relevant for your workflow.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: How to avoid merge conflicts while merging INT changes into Master

[Igor Djordjevic]

On Thursday, July 13, 2017 at 10:54:38 PM UTC+2, Philip Oakley wrote:

> I just want to comment on Buga's 
> > It`s not about what you retain, but what you drop -- with "checkout 
> --ours/theirs", you effectively drop all the changes from one of the 
> branches, and I didn`t get the impression that`s what the user wanted, as 
> he never mentioned that.
>  
> statement.
>  
> The "--ours/--theirs" options are not what we think they are!
>  
> They say that we should fully merge everything in the normal way, and only 
> if we have some minor local conflicts then Git should be biased to one side 
> or the other in terms of performing a perfect, *apparently* conflict-free, 
> merge.
>  
> So what you get is everyhing on master, and everything on INT, with just a 
> little bit of master's code missing where INT won coin toss (or the opposit 
> for the other option). 
>  
> I too had that misunderstanding for a while.
>

Just pay attention that we are talking about `git *checkout *--theirs 
` here for solving conflicts that already appeared after `git merge`, 
in which case you nuke all the changes from one side, even those that would 
have otherwise be accepted through `git *merge *--strategy-option=theirs`, 
which seems to be what you`re talking about. It`s not the same.

And in case you`re not absolutely sure what you want to accomplish, `git 
merge --strategy-option=theirs` may be even worse, as you end up with some 
parts being merged cleanly from both sides (where there were no conflicts), 
and some parts totally dropping one of the sides (where conflicts 
appeared), as you already pointed out.

Regards,
Buga

- Original Message - 
> *From:* Igor Djordjevic  
> *To:* Git for human beings  
> *Sent:* Thursday, July 13, 2017 8:58 PM
> *Subject:* Re: [git-users] Re: How to avoid merge conflicts while merging 
> INT changes into Master
>
> On Thursday, July 13, 2017 at 6:13:44 AM UTC+2, Maheshwaran A N wrote: 
>>
>> On Thursday, 13 July 2017 03:27:06 UTC+5:30, Igor Djordjevic wrote: 
>>>
>>> On Wednesday, July 12, 2017 at 6:38:35 PM UTC+2, Yubin Ruan wrote: 
>>>>
>>>> 2017-07-12 20:40 GMT+08:00 Maheshwaran A N <avpal...@gmail.com>: 
>>>>
>>> > On Tuesday, 11 July 2017 07:36:47 UTC+5:30, Anjaiah Yamagani wrote: 
>>>> >> 
>>>> >> Hi Team, 
>>>> >> 
>>>> >> I have very quick question - as I'm new to the git 
>>>> >> 
>>>> >> we have master branch. 
>>>> >> 
>>>> >> and checked out the INT branch from the master, worked on the INT 
>>>> for an 
>>>> >> month and all the developers pushed the code to INT , obviously INT 
>>>> branch 
>>>> >> ahead of comments then the master. 
>>>> >> 
>>>> >> Now while we try to push the code to the Master it shows conflicts, 
>>>> how to 
>>>> >> avoid this. 
>>>> >> 
>>>> >> at this stage I do not want to see the conflicts and work with the 
>>>> >> developers at this stage and resolve the merge conflicts. 
>>>> >> 
>>>> >> can you suggest are we doing any wrong thing here. 
>>>> >> 
>>>> >> Regards, 
>>>> >> Anjaiah
>>>
>>> >
>>>
>>> > I suppose you are trying to execute the below commands. 
>>>> > 
>>>> > git checkout master 
>>>> > git merge origin/INT (taking changes from remote branch)  or git 
>>>> merge INT 
>>>> > (merge with local changes) 
>>>> > At this point you would have faced the conflicts. 
>>>> > In this case, if you want to retain the changes of INT, you can take 
>>>> the 
>>>> > changes from INT and apply it in master without opening the file and 
>>>> solving 
>>>> > the conflicts. Execute the below command 
>>>> > 
>>>> > git checkout --theirs  
>>>>
>>>> wow, wasn't aware of that! Many thanks! 
>>>>
>>>> /Yubin 
>>>>
>>>> > git add  
>>>> > 
>>>> > Now, you can check in master branch for INT contents for conflicted 
>>>> file. 
>>>>
>>>
>>> I`m not sure how this helps resolving merge conflicts, as it doesn`t 
>>> only retain all changes from INT, but effectively nukes all changes from 
>>> master branch and just takes INT branch file state as-is -- so you`re not 
>

Re: [git-users] Re: How to avoid merge conflicts while merging INT changes into Master

[Igor Djordjevic]

On Thursday, July 13, 2017 at 6:13:44 AM UTC+2, Maheshwaran A N wrote:
>
> On Thursday, 13 July 2017 03:27:06 UTC+5:30, Igor Djordjevic wrote:
>>
>> On Wednesday, July 12, 2017 at 6:38:35 PM UTC+2, Yubin Ruan wrote:
>>>
>>> 2017-07-12 20:40 GMT+08:00 Maheshwaran A N <avpal...@gmail.com>: 
>>>
>> > On Tuesday, 11 July 2017 07:36:47 UTC+5:30, Anjaiah Yamagani wrote: 
>>> >> 
>>> >> Hi Team, 
>>> >> 
>>> >> I have very quick question - as I'm new to the git 
>>> >> 
>>> >> we have master branch. 
>>> >> 
>>> >> and checked out the INT branch from the master, worked on the INT for 
>>> an 
>>> >> month and all the developers pushed the code to INT , obviously INT 
>>> branch 
>>> >> ahead of comments then the master. 
>>> >> 
>>> >> Now while we try to push the code to the Master it shows conflicts, 
>>> how to 
>>> >> avoid this. 
>>> >> 
>>> >> at this stage I do not want to see the conflicts and work with the 
>>> >> developers at this stage and resolve the merge conflicts. 
>>> >> 
>>> >> can you suggest are we doing any wrong thing here. 
>>> >> 
>>> >> Regards, 
>>> >> Anjaiah
>>
>> >
>>
>> > I suppose you are trying to execute the below commands. 
>>> > 
>>> > git checkout master 
>>> > git merge origin/INT (taking changes from remote branch)  or git merge 
>>> INT 
>>> > (merge with local changes) 
>>> > At this point you would have faced the conflicts. 
>>> > In this case, if you want to retain the changes of INT, you can take 
>>> the 
>>> > changes from INT and apply it in master without opening the file and 
>>> solving 
>>> > the conflicts. Execute the below command 
>>> > 
>>> > git checkout --theirs  
>>>
>>> wow, wasn't aware of that! Many thanks! 
>>>
>>> /Yubin 
>>>
>>> > git add  
>>> > 
>>> > Now, you can check in master branch for INT contents for conflicted 
>>> file. 
>>>
>>
>> I`m not sure how this helps resolving merge conflicts, as it doesn`t only 
>> retain all changes from INT, but effectively nukes all changes from master 
>> branch and just takes INT branch file state as-is -- so you`re not 
>> "applying it in master", but deleting master changes altogether.
>>
>> Doing this is dangerous, unless you really want to drop all master branch 
>> changes that happened since you branched your INT branch...
>>
>> Am I missing something?
>>
>> If this is exactly what you wanted to point out (dropping all master 
>> changes and taking INT file as-is), then let this be just an additional 
>> note of warning for those that might have missed it, as the original 
>> question seems concerned with solving something else - a real merge 
>> conflict situation, and this answer doesn`t seem to help there. 
>>
>> Regards,
>> Buga 
>>
>  

Requirement is to keep all the changes of INT. When you have multiple files 
> to solve the conflicts and you very well know which branch to retain, then 
> why not use ours/theirs? Whats dangerous here? User is very clear on what 
> needs to be retained. 


It`s not about what you retain, but what you drop -- with "checkout 
--ours/theirs", you effectively drop all the changes from one of the 
branches, and I didn`t get the impression that`s what the user wanted, as 
he never mentioned that.

He didn`t say he wants to retain INT changes in favor of master (loosing 
master branch changes after the merge), but was merely asking how to deal 
with merge conflicts which he doesn`t want to deal with _at the moment_ -- 
and I`m afraid there`s no easy answer to this, as Philip already pointed 
out.

"Resolving" merge conflicts by using "checkout --theirs", he would drop all 
the changes from master, not for the moment, but _for good_, and he should 
be aware of that -- again, as it doesn`t seem that`s what he wanted, thus 
it`s dangerous to propose without explaining all the implications.
 

> Also, if you retain INT content, there is no much impact in master since 
> INT is branched out from master as a base(Ideally, master is untouched). 
> Therefore, INT is master+newcontents and i hope thats well tested in INT 
> branch itself. 
>

But it`s already pointed out that master is not untouched, otherwise there 
would be n

[git-users] Re: "Deleted by us" while cherry-picking a gerrit in the same project

[Igor Djordjevic]

Hi Maheshwaran,

On Wednesday, July 12, 2017 at 2:34:44 PM UTC+2, Maheshwaran A N wrote:
>
> 'deleted by us' means the file is deleted in the commit which you are 
> trying to do a cherry-pick. It is not file is deleted by you. Git tells 
> that the file was deleted in some other commit, and allows you to decide to 
> retain it (git add) or to remove it. You can do git cherry-pick --continue 
> once you sort this out.
>

This is incorrect -- it`s exactly the opposite, as the other two answers 
already pointed out.

The file is deleted by you, in your branch in which you`re trying to 
cherry-pick into, and the commit you`re trying to cherry-pick actually 
still has that file and contains some changes for it.

So you get to resolve the conflict by either reintroducing the file in your 
branch (accepting its state from the commit you`re cherry-picking), or you 
get to confirm the file should really stay deleted... as already explained 
in previous messages.

Oh, and this topic is from 2013/2014... just saying :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: How to avoid merge conflicts while merging INT changes into Master

[Igor Djordjevic]

On Wednesday, July 12, 2017 at 6:38:35 PM UTC+2, Yubin Ruan wrote:
>
> 2017-07-12 20:40 GMT+08:00 Maheshwaran A N  >: 
>
> On Tuesday, 11 July 2017 07:36:47 UTC+5:30, Anjaiah Yamagani wrote: 
> >> 
> >> Hi Team, 
> >> 
> >> I have very quick question - as I'm new to the git 
> >> 
> >> we have master branch. 
> >> 
> >> and checked out the INT branch from the master, worked on the INT for 
> an 
> >> month and all the developers pushed the code to INT , obviously INT 
> branch 
> >> ahead of comments then the master. 
> >> 
> >> Now while we try to push the code to the Master it shows conflicts, how 
> to 
> >> avoid this. 
> >> 
> >> at this stage I do not want to see the conflicts and work with the 
> >> developers at this stage and resolve the merge conflicts. 
> >> 
> >> can you suggest are we doing any wrong thing here. 
> >> 
> >> Regards, 
> >> Anjaiah

>

> I suppose you are trying to execute the below commands. 
> > 
> > git checkout master 
> > git merge origin/INT (taking changes from remote branch)  or git merge 
> INT 
> > (merge with local changes) 
> > At this point you would have faced the conflicts. 
> > In this case, if you want to retain the changes of INT, you can take the 
> > changes from INT and apply it in master without opening the file and 
> solving 
> > the conflicts. Execute the below command 
> > 
> > git checkout --theirs  
>
> wow, wasn't aware of that! Many thanks! 
>
> /Yubin 
>
> > git add  
> > 
> > Now, you can check in master branch for INT contents for conflicted 
> file. 
>

I`m not sure how this helps resolving merge conflicts, as it doesn`t only 
retain all changes from INT, but effectively nukes all changes from master 
branch and just takes INT branch file state as-is -- so you`re not 
"applying it in master", but deleting master changes altogether.

Doing this is dangerous, unless you really want to drop all master branch 
changes that happened since you branched your INT branch...

Am I missing something?

If this is exactly what you wanted to point out (dropping all master 
changes and taking INT file as-is), then let this be just an additional 
note of warning for those that might have missed it, as the original 
question seems concerned with solving something else - a real merge 
conflict situation, and this answer doesn`t seem to help there. 

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Uncommiting a merge?

[Igor Djordjevic]

Hi Michael,

On Saturday, July 8, 2017 at 3:03:42 AM UTC+2, Michael Gersten wrote:
>
> So I did a merge, edited the conflicts, and committed the result. Looking 
> over the commit, I saw that I missed a conflict marker. 
>
> No bigger. "git reset head^", fix it up, and re-commit, right?
>

Not really, you could have fixed it up right away (without resetting), and 
"re-commit" with:

(*1*) $ git commit --amend --no-edit

... which is what you actually wanted to do anyway, amend the last (merge) 
commit ;)

No, for some reason, that wants to commit a normal commit, not a merge 
> commit. 
> The second parent is missing. 
>

This is as expected -- with your `git reset HEAD^` you dropped your last 
(merge) commit, returning to previous commit but keeping the uncommited 
changes. By "re-commit", I assume you mean plain `git commit`, and that 
makes a regular, single parent commit, not a merge commit -- Git has no 
idea of your previous merge commit at this point, nor that you want to make 
one now.

How do I make it come back?
>

In your current situation, you can reset again to drop the unwanted 
non-merge commit, and then manually create "MERGE_HEAD" file inside your 
".git" folder, containing the hash of the second parent you want your merge 
commit to contain, for example:

(*2*) $ git reset --soft HEAD^
$ echo *second-parent-sha1* >.git/MERGE_HEAD

With that file present and set, doing `git commit` will make a merge 
commit, setting the second parent as you want it.


But in general case, doing (*1*) as explained above and avoiding 
unnecessary hassle seems more preferable :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: multiple projects sharing submodules optimization?

[Igor Djordjevic]

Hi Yue,

On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, yueli...@gmail.com wrote:
>
> The "git worktree add" will give the .git file of submodule the right path 
> automatically, so you don't touch that file. 
> And it creates extra folder "worktree" which store some necessary data for 
> using different working tree.
>

Yes, I already addressed this in my previous e-mail (note the last sentence 
in the quote below), where I perceived the "extra" worktree related stuff 
unnecessary, and just "polluting" the submodule repository.

On Wednesday, June 21, 2017 at 10:33:37 PM UTC+2, Igor Djordjevic wrote:
>
> What looks like an easier (and less intrusive) solution may be to just 
> edit the ".git" _file_ of each submodule we want to reroute (and then 
> delete corresponding submodule repository inside ".git/modules/", as 
> already mentioned) -- this is basically what step 5 described above does to 
> ".git" file, but here without other (unneeded and might be unwanted) 
> "worktree" related stuff.
>
 
On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, yueli...@gmail.com wrote:

> Only modify the .git file of submodule, well, two working tree will use 
> the same index file, the same branch, the same HEAD file, ... mum... as 
> you said, something wrong. :P
> (suppose that's way git introduce the worktree feature since git 2.5.)
>

Yeah, after playing with it for a while, I tend to agree with this now. 
Even further, I`d say the "worktree" approach might be actually a natural 
solution for the "problem" in question, as that is basically what the idea 
was - to have a single submodule repository with multiple working trees 
(one per project that`s using it), and as the repository really should be 
aware of all these working trees so they don`t get out of sync, "worktree" 
pops out on its own.

On Thursday, June 22, 2017 at 4:50:21 AM UTC+2, yueli...@gmail.com wrote:
>
> For example:
>   projects/project1/.git/modules/library_XYZ/*worktrees*/library_XYZ/
> *HEAD*
>

I was actually surprised to see that:

   projects/project1/.git/modules/library_XYZ/worktrees/library_XYZ/HEAD

... inside the ".git" file was correctly recognized as a submodule, with 
that additional stuff appended at the end (not that I`m a git expert, but 
still ;), in comparison to what would a "submodule" approach contain there 
(just the first part, omitting marked suffix).
 

> Another HEAD file for project2/library_XY!
>
> Those worktree data allow project2/library_XYZ to use its own checkout 
> commit and different working tree from project1/library_XYZ. Cool! :D
>

And this is a huge thing, even though I still don`t really like the feeling 
of submodule repository being kind of aware of other projects using it 
(through dedicated per project branches and working trees), it does feel as 
a sane and natural approach... I guess :)

ASFAIK, you still can use "submodule update" for daily work. suppose 
> no drawbacks. :)
>

Basically, I`m only concerned with submodule ".git" file looking a bit 
differently than in a "clean" submodule approach, and if that additional 
"/worktrees/.../HEAD" stuff at the end could cause any issues in every day 
work from within the project repository, using the submodule.

But anyway, thanks for a chance to learn something new :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Should 'git revert' provide an option to ignore the patch context?

[Igor Djordjevic]

On Thursday, June 22, 2017 at 1:00:05 PM UTC+2, Harry wrote:
>
> I found your response very helpful, Buga, especially the last part where 
> you apply the patch in reverse without the unified diff context.
>
> Thanks and regards,
> /HS
>

No problem, I`m glad it helped, I learned something new as well :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: multiple projects sharing submodules optimization?

[Igor Djordjevic]

On Wednesday, June 21, 2017 at 10:33:37 PM UTC+2, Igor Djordjevic wrote:
>
> Hi Yue,
>
> On Wednesday, June 21, 2017 at 3:18:09 AM UTC+2, yueli...@gmail.com wrote:
>>
>> After some tests, I got a better way to do that: Just use git worktree 
>> feature.
>>
>> Here is an example:
>>
>> Suppose you have 2 (or more) projects, and they use a library_XYZ 
>> submodule:
>> /home/projects/project1/library_XYZ
>> /home/projects/project2/library_XYZ
>>
>> Then, you just need to do these:
>>
>> 1. Delete /home/projects/project2/library_XYZ
>> because the coming worktree command needs no folder there
>> 2. Delete /home/projects/project2/.git/modules/library_XYZ
>> no need it anymore, just save your hard disk space. :P
>>
>> 3. cd /home/projects/project1/library_XYZ
>>
>> 4. Create a branch "project2" in /home/projects/project1/library_XYZ
>> if you don't have a branch for the coming worktree
>>
>> 5. run "git worktree add ../../project2/library_XYZ project2"
>> this is the magic commend. :D
>>
>
> I`m not sure if "git-worktree" is the right tool for the job here... While 
> the proposed steps do seem to work from the perspective of "project2" so 
> far, "project1/library_XYZ" submodule is effectively "polluted" with an 
> extra branch ("project2") and an additional (linked) working tree attached 
> to it.
>
> This feels hacky to say the least - I`m not sure if there are any 
> unexpected drawbacks from usability perspective, but it`s certainly does 
> not seem necessary to accomplish the desired goal.
>
> What looks like an easier (and less intrusive) solution may be to just 
> edit the ".git" _file_ of each submodule we want to reroute (and then 
> delete corresponding submodule repository inside ".git/modules/", as 
> already mentioned) -- this is basically what step 5 described above does to 
> ".git" file, but here without other (unneeded and might be unwanted) 
> "worktree" related stuff.
>
> For the given example of two projects using the same submodule:
>
> (*1*) /home/projects/project1/.git << project 
> repository
> /home/projects/project1/.git/modules/library_XYZ << submodule 
> repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/.git/modules/library_XYZ << submodule 
> repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
> ... we can edit "/home/projects/project2/library_XYZ/.git" file to point 
> to "library_XYZ" submodule repo inside "project1", by changing this:
>
> (*2*) gitdir: ../.git/modules/library_XYZ
>
> ... to this:
>
> (*3*) gitdir: ../../project1/.git/modules/library_XYZ
>
> ... and deleting "/home/projects/project2/.git/modules/library_XYZ" 
> submodule repository as it`s not used anymore (as explained above), getting 
> to this (note we have submodule repository only once now):
>
> (*4*) /home/projects/project1/.git << project 
> repository
> /home/projects/project1/.git/modules/library_XYZ << submodule 
> repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
>
> Even better, if possible/preferred, we could make the situation look like 
> this:
>
> (*5*) /home/projects/library_XYZ/.git  << project repository
> /home/projects/project1/.git << project repository
> /home/projects/project1/library_XYZ/*.git* << submodule *file*
> /home/projects/project2/.git << project repository
> /home/projects/project2/library_XYZ/*.git* << submodule *file*
>
> ... where we can than have a "clean and obvious" repository for 
> "library_XYZ" outside of any other project, and just reroute all submodule 
> files inside other projects to it.
>
> For the given example of "/home/projects/project1/library_XYZ/.git" and 
> "/home/projects/project2/library_XYZ/.git" files, edit them to:
>
> (*6*) gitdir: ../../library_XYZ/.git
>
>
> *p.s.* If "/home/projects/project*X*/library_XYZ/.git" is a Git 
> _repository_ and not a file (and "/home/projects/project*X*/.git/modul

[git-users] Re: multiple projects sharing submodules optimization?

[Igor Djordjevic]

Hi Yue,

On Wednesday, June 21, 2017 at 3:18:09 AM UTC+2, yueli...@gmail.com wrote:
>
> After some tests, I got a better way to do that: Just use git worktree 
> feature.
>
> Here is an example:
>
> Suppose you have 2 (or more) projects, and they use a library_XYZ 
> submodule:
> /home/projects/project1/library_XYZ
> /home/projects/project2/library_XYZ
>
> Then, you just need to do these:
>
> 1. Delete /home/projects/project2/library_XYZ
> because the coming worktree command needs no folder there
> 2. Delete /home/projects/project2/.git/modules/library_XYZ
> no need it anymore, just save your hard disk space. :P
>
> 3. cd /home/projects/project1/library_XYZ
>
> 4. Create a branch "project2" in /home/projects/project1/library_XYZ
> if you don't have a branch for the coming worktree
>
> 5. run "git worktree add ../../project2/library_XYZ project2"
> this is the magic commend. :D
>

I`m not sure if "git-worktree" is the right tool for the job here... While 
the proposed steps do seem to work from the perspective of "project2" so 
far, "project1/library_XYZ" submodule is effectively "polluted" with an 
extra branch ("project2") and an additional (linked) working tree attached 
to it.

This feels hacky to say the least - I`m not sure if there are any 
unexpected drawbacks from usability perspective, but it`s certainly does 
not seem necessary to accomplish the desired goal.

What looks like an easier (and less intrusive) solution may be to just edit 
the ".git" _file_ of each submodule we want to reroute (and then delete 
corresponding submodule repository inside ".git/modules/", as already 
mentioned) -- this is basically what step 5 described above does to ".git" 
file, but here without other (unneeded and might be unwanted) "worktree" 
related stuff.

For the given example of two projects using the same submodule:

(*1*) /home/projects/project1/.git << project repository
/home/projects/project1/.git/modules/library_XYZ << submodule repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/.git/modules/library_XYZ << submodule repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*

... we can edit "/home/projects/project2/library_XYZ/.git" file to point to 
"library_XYZ" submodule repo inside "project1", by changing this:

(*2*) gitdir: ../.git/modules/library_XYZ

... to this:

(*3*) gitdir: ../../project1/.git/modules/library_XYZ

... and deleting "/home/projects/project2/.git/modules/library_XYZ" 
submodule repository as it`s not used anymore (as explained above), getting 
to this (note we have submodule repository only once now):

(*4*) /home/projects/project1/.git << project repository
/home/projects/project1/.git/modules/library_XYZ << submodule repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*


Even better, if possible/preferred, we could make the situation look like 
this:

(*5*) /home/projects/library_XYZ/.git  << project repository
/home/projects/project1/.git << project repository
/home/projects/project1/library_XYZ/*.git* << submodule *file*
/home/projects/project2/.git << project repository
/home/projects/project2/library_XYZ/*.git* << submodule *file*

... where we can than have a "clean and obvious" repository for 
"library_XYZ" outside of any other project, and just reroute all submodule 
files inside other projects to it.

For the given example of "/home/projects/project1/library_XYZ/.git" and 
"/home/projects/project2/library_XYZ/.git" files, edit them to:

(*6*) gitdir: ../../library_XYZ/.git


*p.s.* If "/home/projects/project*X*/library_XYZ/.git" is a Git 
_repository_ and not a file (and "/home/projects/project*X*/.git/modules/
library_XYZ" repository probably does not exist), you can run:

(*7*) $ git submodule absorbgitdirs

... inside every "project*X*" repository, so submodule "library_XYZ" 
repository is moved from "/home/projects/project*X*/library_XYZ/.git" to "
/home/projects/project*X*/.git/modules/library_XYZ", and "
/home/projects/project*X*/library_XYZ/.git" becomes a file you can 
edit/reroute, deleting "/home/projects/project*X*/.git/modules/library_XYZ" 
afterwards, as explained above.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Should 'git revert' provide an option to ignore the patch context?

[Igor Djordjevic]

Hi Harry,

On Wednesday, June 14, 2017 at 6:12:28 PM UTC+2, Harry wrote:
>
> I had posted my question earlier on StackOverflow, here: 
> 
> https://stackoverflow.com/questions/44543219/git-revert-unable-to-undo-an-individual-commit-even-in-a-simple-case
>

I`d say you got a pretty straight answer there already, but let`s try to 
address the questions you`ve raised here as well.


*1. *Would having a new option (such as *--ignore-patch-context *) while 
> doing *git revert* make sense?
>

While being possible, whether it would make sense is arguable, as using 
context-free patches is already discouraged as unsafe in general (see 
*git-apply 
--unidiff-zero*[1] 
).

But, as it`s already implemented for `git-apply`, it might make sense to 
have it for `git-revert` as well, being noted as discouraged in the same 
manner...? And I guess nobody needed it much so far, thus it`s not 
implemented yet?

That said, you`re free to bring the discussion to the main *Git mailing 
list*[2]  (that`s where the development happens), and 
try the patch yourself :) Please note that only plain-text e-mails are 
accepted, no HTML.


This option when used would carry out the *revert* mechanically/blindly and 
> leave the result in an uncommitted state (with maybe a warning on the 
> console), allowing the user to verify things for syntax and semantics 
> before committing.  
>

Now, might be you`re not seeing it that way, but this is _exactly_ what Git 
is doing - it carries out the revert mechanically/blindly and leaves the 
result in uncommited state (with merge conflict warning on the console), 
allowing the user to verify things for syntax and semantics before 
_resolving merge conflicts_ and commiting.

The only difference is that instead of your proposed _changing_ of the 
merge result by trying a lucky guess on what should the final state be 
(disregarding context, which is certainly not a blind/mechanical thing to 
do), making it harder for user to comprehend what actually happened, it 
_really_ does its thing blindly (respecting the context), taking both sides 
of the change (before/after) and leaving them as-is for the user to make 
sense of it.

For "simple case" you`re discussing here (simple for human, that is, still 
not for a machine), it`s trivial for a user to make sense of the merge 
conflicts and resolve them correctly (and easily/quickly), and you even 
have various GUI tools to help if raw conflict markers confuse you.


All this said, let me tell you that what you want is actually already 
possible with Git... ;) Well, might be not as directly as you hoped for, 
but instead of your:

(*1*) $ git revert master^^

... step, what you could try doing is this:

(*2*) $ git show master^^ >bug.patch
(*3*) $ git apply --reverse --unidiff-zero bug.patch

Command on line (*2*) creates a "bug.patch" file holding the diff/patch 
that "bug" commit introduced. Command on line (*3*) applies this patch, but 
in reverse (note the `--reverse` parameter), so instead of adding the "Bug" 
line it removes it, and `--unidiff-zero` parameter tells it to disregard 
context lines - which is exactly what you`re looking for... :) Now you can 
review the change, and commit it.

For a safety measure, please note again that usage of context-free patches 
is discouraged, being more error-prone.


2. Is there any documentation where such details of the operations (such as 
> *revert*, *merge, *...) are described?
>

Not sure if this is what you have in mind, but there`s Git *reference 
manual*[3]  (holding more info on *git-revert*[4] 
 and *git-merge*[5] 
 as well).

[1] https://git-scm.com/docs/git-apply#git-apply---unidiff-zero
[2] g...@vger.kernel.org
[3] https://git-scm.com/docs
[4] https://git-scm.com/docs/git-revert
[5] https://git-scm.com/docs/git-merge

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Do I need a git repository for every directory or just one for the root directory?

[Igor Djordjevic]

Hi Peter,

On Thursday, June 1, 2017 at 9:35:43 PM UTC+2, pro...@ucsd.edu wrote:
>
> How does git handle multiple directories and sub-directoreis?
> 'm developing a system with code files in several different directories & 
> sub-directories, but when I search the git manual I find nothing about 
> directories.
>

You don`t need a Git repository for every directory, but only one 
repository for the root directory, and it will track everything all the way 
down from there, recursively -- everything you tell it to track, actually, 
as Philip already mentioned.

Note again that Git tracks _files_ (content, to be precise), so if you have 
empty directories, or directories with untracked files only, Git won`t 
bother with those directories, as it finds them irrelevant, no content to 
track in there.

That sad, you certainly _can_ have more Git repositories one inside another 
as there may be valid reasons you would want to do so, but that usually 
involves some more Git knowledge, and might be you shouldn`t be bothered 
with it for now :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] keeping two branches with partially different history in sync

[Igor Djordjevic]

Hi Matevz,

On Thursday, May 18, 2017 at 12:22:09 AM UTC+2, matevz...@borea.si wrote:
>
> thanks for your help, I would give up otherwise, but now I managed to get 
> this working with a special git merge script that automatically performs 
> merge from A to B and vice versa by ignoring (with git merge -s ours) all 
> opposite commits created by automated merge script (by itself), 
>

Would you mind sharing the script, please? I`m curious to see what works 
for you, still struggling to comprehend what benefits merging provides in 
your use-case.
 

> Also with "git merge -s ours" we can select which parts of the history we 
> want to carry forward and which parts not. After performing single merge 
> with -s ours for certain part of the history git will no longer complain 
> about that in future merges (even normal merges) as it has already marked 
> it as merged.
>

This is true, but this "fake merge" is usually used for single way merging 
only, where you`re disregarding part of the history of the branch you`re 
merging from (say, A), kind of declaring it obsolete/superseded by the 
branch you`re merging into (say, B), but keeping the reference to it. Then 
you can keep merging in the same direction (from A to B), having only new A 
commits being included in the the future merge(s) to B.

But as soon as you try to merge the other way around, hoping to merge only 
new commits from B to A, you may be surprised by the outcome, having 
changes contained in your "private" B commits coming along, too, with 
"private" A commit changes now actually being removed inside the very A 
branch - a behavior you already experienced in your simple test repository.

If you instead do another `git merge -s ours` but in a different direction 
first (from B to A), then merging the new commits found on B to A, this 
will work, but it kind of seems as a glorified cherry-picking...? Not sure 
if any advantages you`re looking for in merging, if any in this case, are 
worth the badly messed up history with these repetitive `-s ours` cross 
merges :/

Hey, but if it works for you, I guess all is good :) I`m just curious.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] keeping two branches with partially different history in sync

[Igor Djordjevic]

Hi Matevz,

On Wednesday, May 17, 2017 at 6:15:49 PM UTC+2, matevz...@borea.si wrote:
>
> I managed on simple repository with
> merge -s ours
> To ignore specific commits from the other side.
>
> However in real life repo things get broken pretty soon. A changes are 
> propagated to B and then back to A and are lost in A, but remain in B :-)
>

This is exactly what I referred to as "while possible to accomplish, may be 
rather confusing and greatly complicate our life down the road" in my 
initial reply[1]... :)

[1] https://groups.google.com/d/msg/git-users/ovqx55Fv6bY/vuirLMmXAgAJ

-- 
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] keeping two branches with partially different history in sync

[Igor Djordjevic]

On Wednesday, May 17, 2017 at 9:48:04 PM UTC+2, rh kramer wrote:
>
> I see no evidence your messages are being deleted from this list.  Are you 
> referring to something else?  You do know that (for some reason I don't 
> know) 
> messages that you send to most lists are either not sent back to you or, 
> at 
> least, are not displayed in typical mail clients?
>

Google Groups web interface shows "2 messages have been deleted" in the 
middle of the thread[1]. Not sure what happened, though, as no more info 
seems to be provided...?

[1] https://groups.google.com/forum/?fromgroups#!topic/git-users/ovqx55Fv6bY

-- 
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] Re: git log

[Igor Djordjevic]

On Wednesday, May 10, 2017 at 8:28:12 AM UTC+2, ashok.s...@gmail.com wrote:
>
>  Want to see only 1.2.4-rel's history without master's history.
>
> On Tuesday, May 9, 2017 at 3:34:05 PM UTC-7, ashok.s...@gmail.com wrote:
>>
>> git log --oneline branch-name -->  It lists all the commits. Is there a 
>> filter option with git log to filter only mentioned branch (branch-name) 
>> commits?
>>
>
And how are "1.2.4-rel" and "master" related to each other (commit graph)?

Sylvie already gave you a correct answer, e.g.:

(1) A---B---C---G---H master
 \
  D---E---F feature
  
... or the same thing but using `git log --graph` style:

* H (master)
* G
| * F (feature)
| * E
| * D
|/
* C
* B
* A
  
(2) $ git log --oneline master..feature
F
E
D

(3) $ git log --oneline feature..master
H
G

(4) $ git log --oneline master
H
G
C
B
A

(5) $ git log --oneline feature
F
E
D
C
B
A


"Branch commits", in Git`s eyes, is everything that can be reached from the 
branch tip (pointer).

For the "feature" branch in the above example (1), all its commits are 
shown in command/output example (5) -- and yes, commits A, B and C are 
considered to be a part of both "feature" and "master" branches.

This may not be what _you_ consider "branch commits", where you may prefer 
to see something like output example (2) above, but in order to get more 
help, some more knowledge about your repository would be helpful, 
especially the relation (graph) of the revisions (branches/tags/commits...) 
you`re interested in.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Help with git pull, and restricting what gets pulled

[Igor Djordjevic]

Hi Michael,

On Thursday, April 27, 2017 at 1:42:18 AM UTC+2, Michael Gersten wrote:
>
> Thank you very much.
>

No problem, glad if it helped :)


When I said 
> >   843  git fetch origin refs/pull/12121/head 
> I was under the impression that explicitly fetching a specific branch also 
> set up a tracking branch for it. 
>
> I was not aware that I had to say --track
>

In some general use, you don`t even have to say `--track` nowadays, if you 
try to checkout a branch that does not exist, but Git finds a remote branch 
of the same name, it will be smart and create a new local branch with that 
name for you, setting it to track the remote branch automatically.

For example, in a case like this:

$ git branch --all
* master
  remotes/gkoelln/Dish
  remotes/origin/master

... you can just do (note that local branch "Dish" doesn`t even exist yet):

$ git checkout Dish

... and you`ll get your local remote tracking branch automatically:

Switched to a new branch 'Dish'
Branch Dish set up to track remote branch Dish from gkoelln.


However, in your specific case with "pull request branches" this doesn`t 
seem to work as automatically - maybe because of the "special nature" of 
those pull request "branches" (residing inside "refs/pull/", instead of 
"refs/heads/", on the remote side)...? Not really sure. Yet, `--track` gets 
the job done ;)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Help with git pull, and restricting what gets pulled

[Igor Djordjevic]

Hi Michael,

On Wednesday, April 26, 2017 at 7:31:53 PM UTC+2, Michael Gersten wrote:
>
> So I'm having a "too much pulled" issue, that I'd like help with. 
>
> I'm working with this remote: 
>
> [remote "origin"] 
> url = https://github.com/rg3/youtube-dl.git 
> fetch = +refs/heads/*:refs/remotes/origin/* 
>
>
> I wanted to be able to get pull requests to test and play with, and I was 
> told to add this line: 
>
> fetch = +refs/pull/*/head:refs/remotes/origin/pr/* 
>

By doing this you explicitly said you want *all* pull requests (notice the 
* signs in there). If you wanted to have a specific one updated each time 
you do plain `git fetch`, you may have done it like this instead:

(*1*) fetch = +refs/pull/12121/head:refs/remotes/origin/pr/12121
 
... (notice using specific pull request id, in this case 12121, instead of 
*).


Which worked -- I was able to say 
>   843  git fetch origin refs/pull/12121/head 
>

If you wanted to fetch like this, you don`t need the above mentioned 
.config edit, just that it fetches to FETCH_HEAD, you don`t get a branch 
automatically.

If you want to fetch into a branch, you can do it like this:

(*2*) git fetch origin pull//head:

You can even simulate the remote branch by doing something like this:

(*3*) git fetch origin pull/12121/head:refs/remotes/origin/pr/12121

... or if you edited .config as described in (*1*), you can just do `git 
fetch`, without additional parameters.

To create a local remote tracking branch out of it:

(*4*) git checkout -b pull/12121 --track origin/pr/12121

 

> No problem. 
>
> What was the problem? Doing an update. 
>
> keybounceMBP:youtube-dl michael$ git pull master 
> fatal: 'master' does not appear to be a git repository 
> fatal: Could not read from remote repository. 
>
> Please make sure you have the correct access rights 
> and the repository exists. 
>

Here, you are using `git pull` with a wrong parameter, providing it a 
branch name, where it`s expecting a remote name first (see git-pull[1] 
).


keybounceMBP:youtube-dl michael$ git pull 
> remote: Counting objects: 17909, done. 
> remote: Compressing objects: 100% (112/112), done. 
> remote: Total 17909 (delta 10124), reused 10079 (delta 10078), pack-reused 
> 7717 
> Receiving objects: 100% (17909/17909), 74.44 MiB | 3.01 MiB/s, done. 
> Resolving deltas: 100% (12988/12988), completed with 3257 local objects. 
> From https://github.com/rg3/youtube-dl 
>629dc1892..b876a9cd7  gh-pages -> origin/gh-pages 
>a4d6cf970..3dc8b61b7  master   -> origin/master 
>  * [new ref] refs/pull/0/head -> origin/pr/0 
>  * [new ref] refs/pull/100/head   -> origin/pr/100 
>  * [new ref] refs/pull/10011/head -> origin/pr/10011 
>  * [new ref] refs/pull/10012/head -> origin/pr/10012 
> ... 
>
> So, instead of updating master, like I thought, or just the one pull 
> request I had previously gotten (NB: those would be the only refs I had 
> from that github), I now have lots and lots of things I don't care about or 
> want. 
>

You explicitly said you want *all* the pull requests (as explained above, 
using the * sign), thus this is expected and correct behavior.


My first question is, if I just delete the files from 
> .git/refs/remotes/origin/pr/ that I don't want, will that result in git 
> cleaning up the unwanted branches? 
>

Yes, you can do that manually, or you can do something like this as well:

(*5*) git for-each-ref --format="%(refname:short)" 
refs/remotes/origin/pr/\* | xargs git branch -rD


My second question is: The only way I could manage to update master was: 
>
> keybounceMBP:youtube-dl michael$ git fetch origin master 
> From https://github.com/rg3/youtube-dl 
>  * branchmaster -> FETCH_HEAD 
> keybounceMBP:youtube-dl michael$ git checkout master 
> Switched to branch 'master' 
> Your branch is behind 'origin/master' by 12 commits, and can be 
> fast-forwarded. 
>   (use "git pull" to update your local branch) 
> keybounceMBP:youtube-dl michael$ git pull 
> Updating a4d6cf970..3dc8b61b7 
> Fast-forward 
>  .github/ISSUE_TEMPLATE.md |   6 ++--- 
>
> ... 
>
> So, what is the proper/best usage of fetch/pull? At the moment, I'm 
> interested in these branches: 
> origin master 
> origin refs/pull/12121 
> gkoelln Dish 
>

For what you want, those commands you`ve shown above are correct.


And, while I did explicitly ask for pull request 12121, it did not show up 
> in my remotes -- 
> [branch "master"] 
> remote = origin 
> merge = refs/heads/master 
> [branch "Dish"] 
> remote = gkoelln 
> merge = refs/heads/Dish 
>

Where did you "explicitly ask for pull request 12121" remote tracking 
branch, in order for it to be shown here? I haven`t seen that command in 
your e-mail, so unless you accidentally omitted it, you didn`t actually ask 
for it... yet.


so what do I need to do to 

Re: [git-users] Undocumented reset behavior

[Igor Djordjevic]

On Saturday, April 22, 2017 at 11:14:08 PM UTC+2, vvs wrote:
>
> On Saturday, April 22, 2017 at 11:28:49 PM UTC+3, Philip Oakley wrote:
>>
>> On the main list thare is a similar "issue" [1] regarding the expectation 
>> for `git checkout`, and importantly (for me) these collected views 
>> regarding the "Git Data Protection and Management Principles" is not within 
>> the Git documentation.
>>
>
> Yes, that's an interesting point. What concerns me is that the commit 
> c5326bd62b7e168ba1339dacb7ee812d0fe98c7c which introduced this into 
> checkout isn't consistent with reset. Seems that nobody noticed this before.
>

Interesting observation, might be worth raising on the Git mailing list[1] 
as well, hopefully getting some more insight. A discussion that seems to 
predate the mentioned commit[2] can be found here[3].

That said, I`m not sure the current "checkout" isn`t consistent with 
"reset", but more that they both exhibit the same "glitch"(?) in certain 
occasions, where the same content file is still overwritten (timestamp 
updated), which does seem unexpected (as file content is unchanged, thus no 
need to update the file). I wouldn`t know if it`s not some optimization 
thing, though, yet it seems that performance would rather be hurt by 
needlessly (re)writing unchanged files... or maybe not? But "make"-alike 
systems are hurt for sure, triggering an unnecessary rebuild.

Taking your first example as a base, if we do:

(1) git reset HEAD^
(2) git checkout @{1} -- yyy

... then timestamp is updated (file overwritten), even though the 
(untracked) file had the same content (both index and working tree get 
updated). But if we now do this instead:

(3) git checkout @{1}

... then the "yyy" timestamp is left intact (might be due to already 
updated index, same as in your "reset" case?).

So it looks like in both cases (`git checkout $tree $file` and `git reset 
--hard`), if file does not exist in the index yet (it`s untracked), it gets 
written out, even if the same file already exists in the working tree 
(which is then needlessly overwritten, timestamp updated accordingly).

[1] g...@vger.kernel.org
[2] https://github.com/git/git/commit/c5326bd62b7e168ba1339dacb7ee812d0fe98c7c
[3] 
https://public-inbox.org/git/xmqqbnoa29ps@gitster.dls.corp.google.com/T/#u

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: merge conflicts

[Igor Djordjevic]

>
> On Monday, April 3, 2017 at 9:07:14 PM UTC+2, Pablo Rodríguez wrote:
>>
>> I thought the same happened with different lines (the latter modified 
>> line is kept in the merged file), but I can’t say for sure after 
>> experiencing the merge conflicts.
>>
>
*p.s.* In regards to this, it`s worth noting that concept of "latter 
modified line", while actually pretty easily defined, might be done so 
pretty unexpectedly for a new Git user.

Taking the previous e-mail laptop/desktop example further, one could 
expect that a version done today on the desktop computer is clearly 
an updated one in regards to a version made yesterday on the laptop 
computer, and that there shouldn`t be any merge conflicts even if the 
same line inside the file is modified on both sides (laptop/desktop) 
- just take the newest file (time-wise) line version.

But for Git, that doesn`t have to be true at all.

As Git is distributed by nature, meaning that people can collaborate 
rather _independently_ and _equally_ (no one`s version is "more 
important" in Git`s eyes), a version isn`t considered to be "latest" 
in terms of simple timestamps (when was the change made), but in 
terms of history graph flow (which version on the graph the change is 
connected to).

We just can`t expect that time is synchronized between different 
computers so it realistically shows which version is really "newer".

But even if we could, Git still allows us to work on the changes 
independently of all the others, of their changes and working pace, 
so even if we make some change in our version after someone else did 
(time-wise), that still doesn`t mean that we weren`t just slower to 
produce our version, and that the other person didn`t provide what 
should be considered an update in comparison to our work already.

Back to our laptop/desktop example. This is how could the history 
graph look like:

   D (laptop)
  /
  ---A---B---C
  \
   E (desktop)

Version C is the last synchronized one, where versions D and E are 
changes made on laptop and desktop respectively. No matter _when_ 
where versions D and E made (in comparison to each other), we must 
not conclude anything from that - they are to be considered equally 
important.

The only thing we know for certain here is that version B is newer 
than version A, version C newer than version B, and versions D and E 
newer than version C (but equally "new" in comparison to each other).

When attempting a merge M:

   D
  / \
  ---A---B---C   M (sync)
  \ /
   E

... all the rules explained in the previous e-mail apply, where the 
same file line change in both version D and E raises a conflict, 
unable to be automatically resolved by what could otherwise 
unknowingly be perceived as a simple "latest/newest update" logic.

-- 
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] Re: merge conflicts

[Igor Djordjevic]

Hi Pablo,

On Monday, April 3, 2017 at 9:07:14 PM UTC+2, Pablo Rodríguez wrote:
>
> Dear list, 
>
> although I have been using git for almost three years, I have used it 
> only for my writings (I cannot code). 
>
> This reduces the need for branches and the possibility of merge 
> conflicts. I experienced less than five, due to the fact of working in 
> different computers (and having forgotten to sync repos the right way). 
>
> My question is simple: what causes a merge conflict? 
>
> I mean, changes in different files are merged fine, since the most 
> updated version of each is merged. 
>
> I thought the same happened with different lines (the latter modified 
> line is kept in the merged file), but I can’t say for sure after 
> experiencing the merge conflicts. 
>
> Could you confirm whether lines are merged independently or whether 
> there is always a conflict when one tries to pull a modified file from 
> remote in a file that was also modified after latest push in local?
>

On top of what Konstantin already said, here`s an example.

Let`s say you have a file "demo.txt" synced on both your laptop and 
desktop computer. The file contents may look like this:

  First
  Second
  Third
  Fourth

Now, you edit the file on your laptop, and make it look like this:

  First
> 2nd
  Third
  Fourth
> 5th
  
Later, you go to your desktop, forget to sync with your laptop first, 
but edit the file to look like this:

  First
> Second best
  Third
  Fourth

Now, if you try to sync/merge with your laptop, you`ll get a merge 
conflict...

Important thing to notice here is that there is no merge conflict for 
the fifth line, Git will recognize that you added "5th" at the end of your 
file`s laptop version, and merge that happily, no conflicts.

So, answering your question directly, yes, the file which was 
modified on both sides of the merge (local and remote, for example) 
can be merged without conflicts - as long as the changed lines are 
not overlapping...

... which brings us to the merged example file "Second" line, where the 
situation is not that clear - both laptop and desktop versions of the 
file changed it from original "Second" value. Should the merged 
version now be saying "2nd", "Second best", maybe "2nd best" or even 
something totally different...?

Even if it may be pretty clear to you, Git can`t sensibly know that, 
and instead of trying to automatically do something which could be 
wrong, it complains about the conflict which you need to analyse and 
resolve yourself.


In the end, I would just emphasize what Konstantin already mentioned 
as well, but in regards to the given example - Git doesn`t compare 
file lines by their _position_ in the file (second line vs. second 
line), as one might wrongly deduct from this simple demo, but rather 
by their _context_ (line between unchanged lines "First" and "Third" 
here, in reality taking several "context" lines before and after the 
changed one, for a good measure).

This might be a common knowledge already, but could be worth a 
mention, just in case.


To conclude, some more examples.

If you started with the synchronized "demo.txt" file:
 
  First
  Second
  Third
  Fourth 
 
... and made changes like this:

Laptop:
> Beginning
> 0
  First
  Second
  Third
  Fourth

Desktop:
  First
  Second
> 3rd
  Fourth

... your later merge attempt will not produce any conflicts, 
resulting in this:

> Beginning
> 0
  First
  Second
> 3rd
  Fourth

Here, Git successfully recognized that you added some text before 
"First" line (lines "Beginning" and "0"), and that you also changed 
line "Third" to "3rd" - even though the line position is not the same 
any more, the context is, it`s still between unchanged lines "Second" 
and "Fourth".


Another one, again starting with:

  First
  Second
  Third
  Fourth

... and making changes like this:

Laptop:
  First
> 2nd
  Third
  Fourth

Desktop:
  First
> 2nd best
  Third
  Fourth

If you try to merge these two versions of the same file, you`ll end 
up with a merge conflict, as they both changed "Second" to "2nd" and 
"2nd best", respectively.

Again, the solution might be clear to you, but if you think about it 
a bit, it may not be to anyone else (like Git, but even another human 
being), not knowing what you really wanted to accomplish in the first 
place (keep or remove the "best" part, for example)... Thus, you get 
a conflict, and the honors to resolve it manually in whatever way you 
prefer :)


Hope all this helps a bit.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: I have to figure out git by Thu or be fired...

[Igor Djordjevic]

Do you need to figure out how to _use_ Git in everyday work, or how Git 
itself works _internally_?

I may assume it`s the former, but asking about "tree" makes me wonder - 
that said, how computer savvy are you in the first place, and what would 
your desired context/flow of using Git be?

Before needlessly drowning you in stuff you may not be that familiar with 
(and which you could avoid), it might be good to know what do you really 
need, so you may get the answer that helps you the most, without creating 
even more unnecessary confusion and headaches.

Regards,
Buga

On Sunday, April 2, 2017 at 4:41:54 AM UTC+2, bestbrightes...@gmail.com 
wrote:
>
> Any suggestions? This company uses bitbucket and sourcetree. Is there a 
> tutorial (that works) that I could view?
> One specific question is, what exactly is a tree in computer terms? I'm 
> guessing it is a directory, so how do I list the contents of the 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] Re: Help with rebase?

[Igor Djordjevic]

Hi Michael,

Having some more time now, here`s a bit more elaborate answer, mentioning 
the rebasing flow, if you prefer that instead.

On Saturday, March 25, 2017 at 2:22:09 AM UTC+1, Michael Gersten wrote:
>
>
> So here is what I'm trying to do. 
>
> "Master", in this case, is the rg3 (primary) github repository of 
> youtube-dl. 
> It gets an update about every 2 days. 
> https://github.com/rg3/youtube-dl.git 
>
> "Dish" is a pull request that adds in support for Dish networks to the 
> Adobe Pass authentication scheme. It works, but is not yet in the official 
> codebase. It comes from 
> git fetch https://github.com/gkoelln/youtube-dl.git Dish 
>
> I am not making changes to either Dish (someone else's code) nor master. 
> I made 'merged-dish' so that I would have something to use without getting 
> the local copy of either branch dirty. 
>
> So, I did 
>
> git fetch https://github.com/gkoelln/youtube-dl.git Dish 
> git checkout FETCH_HEAD 
> git tag -a Dish 
> git checkout master 
> git checkout -b merged-dish 
> git merge Dish 
> make 
> ... 
>

Is there any special reason that you go through hoops of checking-out 
FETCH_HEAD and tagging it, instead of doing straight `git checkout Dish`? 
That should provide a remote tracking local branch "Dish" which you can 
then just keep rebasing on master with `git rebase master Dish` whenever 
"master" gets updated.
 

> All good. 
>
> Two days later, I have to update youtube-dl. So, a pull on master (clean 
> update), and then the question, what's the best way to keep the Dish 
> patches up to date?
>

In case where you previously did `git checkout Dish` to get the remote 
tracking local branch, you would just need to do `git rebase master Dish`  
(or just `git rebase master` if you`re already on the local "Dish" branch).
 

> So, my thinking is to rebase my copy of the Dish patch onto master, and 
> then compile that. 
>
> What actually worked for me was 
> git rebase --onto master master merged-dish 
> I'm surprised that I had to specify master twice, so I really don't 
> understand the arguments to rebase. 
>

I would actually be surprised if the command you wrote would do anything 
useful (with that "master" specified twice), though maybe I`m missing 
something (in case one "master" gets magically translated to something 
else, which I wouldn`t expect, but I don`t know...). And why do you use 
"--onto"? It doesn`t seem to be needed in your case.

So, to wrap this all up, here`s the flow you may follow to keep "Dish" on 
top of "master" in case where you don`t own any of them, and using `git 
rebase` (for the sake of completeness, I`ve started from scratch, 
initializing a new repository):

(*1*) $ git init
(*2*) $ git remote add -f -t master rg3 
https://github.com/rg3/youtube-dl.git
(*3*) $ git remote add -f -t Dish gkoelln 
https://github.com/gkoelln/youtube-dl.git
(*4*) $ git checkout master
(*5*) $ git checkout Dish
(*6*) $ git rebase master


After steps (5) and (6), the graphs should look something like this:

(*5*) ---A---B---C---D---E---F (master, rg3/master)
\
 Z (Dish, gkoelln/Dish)

(*6*) ---A---B---C---D---E---F (master, rg3/master)
\   \
 Z (gkoelln/Dish)Z' (Dish)


Now your local "Dish" is based on top of latest "master", and all is good.

In the future, each time "rg3/master" gets updated, you can do:

(*7*) $ git checkout master
(*8*) $ git pull
(*9*) $ git rebase master Dish


After steps (8) and (9), the graphs should look something like this:

(*8*) ---A---B---C---D---E---F---G---H---I (master, rg3/master)
\   \
 Z (gkoelln/Dish)Z' (Dish)

(*9*) ---A---B---C---D---E---F---G---H---I (master, rg3/master)
\   \
 Z (gkoelln/Dish)Z'' (Dish)


Once again, your local "Dish" branch is based on top of latest "master" and 
ready to use.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Help with rebase?

[Igor Djordjevic]

Ok, I've just seen your reply.

I'm not sure if what you described is the most convenient flow, but without 
changing it, in case you don't actually make commits on "merged-dish" and you 
want to go with merging, after updating "master" and/or "Dish" you may do:

  git branch -d merged-dish
  git checkout -b merged-dish master
  git merge Dish

This will, once again, provide you with an up-to-date working copy of 
"merged-dish". Rinse, repeat.

-- 
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] Re: Help with rebase?

[Igor Djordjevic]

Two additional notes:

1) Note (*R6*) not using --onto parameter.

2) With rebase flow, the final merge may be given a `--no-ff` parameter, 
causing an explicit merge commit to be created instead of a fast-forward 
merge, giving this situation instead of previously shown (R12):

(*R12a*) ---A---B---C---D---E---F---G---H---M (master)
   \ /
X'''Y'''Z'''W''-V'--U' (Dish)


Some people prefer this to (R12) as it keeps topic branch logically/visibly 
separated from the main flow, providing a clear merge point M (even if 
topic branch "Dish" gets deleted), also making it easier to revert/undo the 
whole topic later, in case needed.


On Saturday, March 25, 2017 at 2:08:40 AM UTC+1, Igor Djordjevic wrote:
>
> Hi Michael,
>
> On Thursday, March 23, 2017 at 10:10:02 PM UTC+1, Michael Gersten wrote:
>>
>> I need help with the syntax of rebase. 
>>
>> I have a branch, "Dish", that was branched off of master. This was about 
>> a month ago. 
>>
>> Making a new branch off master, and merging Dish into it, worked just 
>> fine. No problem. 
>>
>> Now, I have "master", and from it, "merged-dish". 
>>
>> Time to update master. All good so far. 
>>
>> What I want is an easy way to update "merged-dish". So I tried to rebase 
>> it. 
>>
>> git rebase --onto master Dish 
>>
>> git rebase --onto master merged-dish 
>>
>> Both of these were no-ops. 
>>
>> So what's the best way to keep a local branch up to date as the upstream 
>> master updates? 
>>
>
> Until more knowledgeable/experienced people chime in, I`ll try to give 
> some hopefully useful feedback. Anyone, please feel free to correct me or 
> provide additional info I might have missed, I`m still learning myself.
>
> To understand what happened, it might be best to use some visualization of 
> what is going on.
> Prior to your "rebase" attempts, after you updated "master", your history 
> looked something like this: 
>
> (*1*) ---A---B---C---D---E---F (master)
> \   \
>  \   M (merged-dish)
>   \ /
>X---Y---Z (Dish)
>
>
> As you said you`re trying to rebase "merged-dish" now, I`ll assume you`re 
> on the "merged-dish" branch.
>
> (*2*) git rebase --onto master Dish
>
> This means "rebase current branch (merged-dish) on new base `master` 
> (commit F) from old base `Dish` (commit Z)". But what are the actual steps? 
> Let`s see:
>
>1. Find all commits between old base "Dish" (Z) and current branch 
>"merged-dish" (M) (contained in "merged-dish" but not in "Dish"). This 
>results in commits B, C, D (you may expect to see M here, too, but it is 
>missing as "rebase" by default does not preserve merge commits).
>2. Replay these commits on top of new base "master" - but as these are 
>contained inside "master" already, there is nothing to be done here, as 
> you 
>noticed, only "merged-dish" gets updated to point to where "master" is 
>(commit F):
>
> (*3*) ---A---B---C---D---E---F (master, merged-dish)
> \
>  X---Y---Z (Dish)
>
> (depending on the changes you have, you might end up with some merge 
> conflicts during a rebase, but the end result should be as shown above)
>
>
> Now, on to the next one:
>
> (*4*) git rebase --onto master merged-dish
>
> This one confuses me a bit as you didn`t mention if you did anything 
> between this and the previous command, because if you tried it right after 
> the previous one, it doesn`t really make much sense.
>
> Why? If we ended up in a situation shown on graph (3) and tried command 
> (4), the steps to do would look something like this:
>
>1. Find all commits between old base "merged-dish" (F) and current 
>branch "merged-dish" (F) (contained in "merged-dish" but not in 
>"merged-dish")... and as already obvious, this returns nothing, no 
> commits, 
>so there`s nothing to be done in the next step - as you noticed again.
>
>
> All this said, the important question is - what should you have done 
> instead?
>
> As usual, it depends on what you wanted to accomplish in the first place. 
> For example, I`m not sure what was the idea behind "merged-dish" branch...?
>
> Anyway, let`s say this is some starting point:
>
> (*5*) ---A---B---C---D (master)
> \
>  X---Y-

[git-users] Re: Help with rebase?

[Igor Djordjevic]

Hi Michael,

On Thursday, March 23, 2017 at 10:10:02 PM UTC+1, Michael Gersten wrote:
>
> I need help with the syntax of rebase. 
>
> I have a branch, "Dish", that was branched off of master. This was about a 
> month ago. 
>
> Making a new branch off master, and merging Dish into it, worked just 
> fine. No problem. 
>
> Now, I have "master", and from it, "merged-dish". 
>
> Time to update master. All good so far. 
>
> What I want is an easy way to update "merged-dish". So I tried to rebase 
> it. 
>
> git rebase --onto master Dish 
>
> git rebase --onto master merged-dish 
>
> Both of these were no-ops. 
>
> So what's the best way to keep a local branch up to date as the upstream 
> master updates? 
>

Until more knowledgeable/experienced people chime in, I`ll try to give some 
hopefully useful feedback. Anyone, please feel free to correct me or 
provide additional info I might have missed, I`m still learning myself.

To understand what happened, it might be best to use some visualization of 
what is going on.
Prior to your "rebase" attempts, after you updated "master", your history 
looked something like this: 

(*1*) ---A---B---C---D---E---F (master)
\   \
 \   M (merged-dish)
  \ /
   X---Y---Z (Dish)


As you said you`re trying to rebase "merged-dish" now, I`ll assume you`re 
on the "merged-dish" branch.

(*2*) git rebase --onto master Dish

This means "rebase current branch (merged-dish) on new base `master` 
(commit F) from old base `Dish` (commit Z)". But what are the actual steps? 
Let`s see:

   1. Find all commits between old base "Dish" (Z) and current branch 
   "merged-dish" (M) (contained in "merged-dish" but not in "Dish"). This 
   results in commits B, C, D (you may expect to see M here, too, but it is 
   missing as "rebase" by default does not preserve merge commits).
   2. Replay these commits on top of new base "master" - but as these are 
   contained inside "master" already, there is nothing to be done here, as you 
   noticed, only "merged-dish" gets updated to point to where "master" is 
   (commit F):
   
(*3*) ---A---B---C---D---E---F (master, merged-dish)
\
 X---Y---Z (Dish)

(depending on the changes you have, you might end up with some merge 
conflicts during a rebase, but the end result should be as shown above)


Now, on to the next one:

(*4*) git rebase --onto master merged-dish

This one confuses me a bit as you didn`t mention if you did anything 
between this and the previous command, because if you tried it right after 
the previous one, it doesn`t really make much sense.

Why? If we ended up in a situation shown on graph (3) and tried command 
(4), the steps to do would look something like this:

   1. Find all commits between old base "merged-dish" (F) and current 
   branch "merged-dish" (F) (contained in "merged-dish" but not in 
   "merged-dish")... and as already obvious, this returns nothing, no commits, 
   so there`s nothing to be done in the next step - as you noticed again.
   

All this said, the important question is - what should you have done 
instead?

As usual, it depends on what you wanted to accomplish in the first place. 
For example, I`m not sure what was the idea behind "merged-dish" branch...?

Anyway, let`s say this is some starting point:

(*5*) ---A---B---C---D (master)
\
 X---Y---Z (Dish)


MERGE FLOW (M)

If you wanted to update your "Dish" branch with recent commits from 
"master" using a merge, you should have just done that (while on "Dish" 
branch):

(*M6*) git merge master

... which would give you this situation:

(*M7*) ---A---B---C---D (master)
 \   \
  X---Y---Z---M (Dish)


You can then keep working on both "master" and "Dish", and merge from 
"master" to "Dish" when you feel like it***:

(*M8*) ---A---B---C---D---E---F (master)
 \   \
  X---Y---Z---M---W (Dish)

(*M9*) ---A---B---C---D---E---F (master)
 \   \   \
  X---Y---Z---M---W---M2 (Dish)


Finally, when you`re satisfied with your "Dish" completeness, you may merge 
it back to "master":

(*M10*) ---A---B---C---D---E---F---G---H (master)
  \   \   \
   X---Y---Z---M---W---M2--V---U (Dish)

(*M11*) ---A---B---C---D---E---F---G---H---M3 (master)
  \   \   \ /
   X---Y---Z---M---W---M2--V---U (Dish)


You can now delete branch "Dish", keep it for reference, or even merge 
"master" into it (being a fast-forward merge):

(*M12*) ---A---B---C---D---E---F---G---H---M3 (master, Dish)
  \   \   \ /
   X---Y---Z---M---W---M2--V---U


REBASE FLOW (R)

Alternatively, if you wanted to use the rebasing flow, you can just keep 
rebasing "Dish" on top of "master". So in situation (5), you would do this 
instead (while on "Dish" branch):

(*R6*) git rebase master

... which would give you this (in comparison to previous (M7)):

Re: [git-users] Updating a staged file makes it dissappear

[Igor Djordjevic]

Hi AD S,

On Wednesday, March 22, 2017 at 4:22:22 AM UTC+1, AD S wrote:
>
>
> On Tuesday, March 21, 2017 at 4:53:51 PM UTC+10, Gergely Polonkai wrote:
>>
>> Could you show us how you ran checkout? It’s strange to me it staged your 
>> file.
>>
>> If you have a file in the index and adding modifications makes the file 
>> disappear, that means the changes added later negates the changes in the 
>> index.
>>
>> Try it: add a line to an unmodified file, add to the index. Now remove 
>> the file and add again. The index is now empty. This is Git’s way to 
>> prevent you making empty commits.
>>
>> If I were you, I would do the checkout again, and check the contents of 
>> the index with git diff --cached. That may give you a hint on what’s going 
>> on.
>>
>> Gergely
>>
>> On Tue, Mar 21, 2017, 05:07 AD S  wrote:
>>
>>> I made a mistake in the code on a file on a remote repo and so used 
>>> `checkout` to bring it into my branch to fix it. Running `git status` 
>>> immediately after, I see the file is modified and staged.
>>>
>>> I then make my changes to fix the code and run `git status` again and 
>>> see 2 'versions' of the same file - one staged and one not. Makes sense, 
>>> all I got to do is `git add` the unstaged one and it will update the one in 
>>> stage.
>>>
>>> I do this and `git status` again but now stage is now empty. I get the 
>>> message `nothing to commit (working directory clean)`.
>>>
>>> To experiment, I run through the commit, push, merge process and check 
>>> the remote repo, but, of course, the buggy code is still there.
>>>
>>> Would anyone know what's going on here?
>>>
>>
> It's ok, I think I know why this happened, though there are still some 
> questions.
>
> The issue was that I had already fixed the code on my branch sometime 
> earlier, so when I checked-out the file and fixed it again Git could not 
> see any difference between the code held on my branch and the file I had 
> just fixed, so it saw there was no changes and thus nothing to commit.
>
> That's fine.
>

That may not be fine -- I`d say it`s a bit unusual that you "already had 
fixed code on your branch" but not in the working directory (thus you had 
to "fix it again"). But this can probably be explained by your original 
e-mail, saying that you actually checked-out _a file_ from a different 
branch (replacing your existing _and fixed_ file)...? While this may be 
justified, you should really know what you`re doing, and what you may 
expect in return -- as previously discussed in *your other topic* 
.
 

> However, the question now is: if my branch was already up-to-date with the 
> fixed code, why was I not able to merge it with the remote repo that still 
> had the buggy code? When I tried to merge it seemed to work seamlessly - no 
> error messages or conflicts.
>

This may be explained by your checking-out a file from a different branch 
as well, where you can eventually end up with a merge that does not really 
do what you wanted -- and the error in that case is probably on your end, 
might be in your work flow.

I am still new to Git myself, but as far as I know, one doesn`t usually 
checkout a single file from a remote branch in order to work on it - 
instead, you should either create a local branch out of the remote branch 
(if you don`t have it already), or just fetch/merge with your local branch 
(to update it if you already have it). Then you can work on the file as it 
is, in your local branch, being a part of the original commit and following 
the original history, eventually making a commit on the local branch and 
doing a push to update the remote branch with your changes.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] What's the best course of action when you need a file from another branch that is not yet merged with master?

[Igor Djordjevic]

eature branches has achieve the 'separation of 
> concerns' level then each can progress independently without _worry_. 
> Obviously (?) this is best supported by some test platform that helps 
> ensure that important test scenarios aren't broken (even if the Git test 
> suite takes hours on GfW)
>  
>  
> It should be remembered that most peoples views of 'configuration 
> management' is based on ideas that predate the Titanic, where the 'master 
> drawing' were worth more than the old masters (Mona Lisa etc) because if 
> they were damaged you could not build the ship etc. That unique master had 
> to be protected at all costs, and procedure and process reinforced that 
> protection.
>  
> Now we have perfect replication (and verification hashes) in milliseconds 
> for master files, so all the old _worries_ are GONE, and all the old 
> processes and procedures concerning protection of the master need to also 
> go. What must be retained is the authorisation step that identifies the 
> particular revision (and its identical copies) that have a sufficvient 
> quality level to release for 'production'. 
>  
> Most folk do not have a scoobies about this 'titanic' shift that computer 
> based DVCS provides. <Climb's off horse>
>  
> Merge often, merge early, allways test !
>  
> Philip
>
> - Original Message - 
> *From:* Igor Djordjevic  
> *To:* Git for human beings  
> *Cc:* philip...@iee.org  
> *Sent:* Wednesday, March 01, 2017 2:22 AM
> *Subject:* Re: [git-users] What's the best course of action when you need 
> a file from another branch that is not yet merged with master?
>
> 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 th

Re: [git-users] What's the best course of action when you need a file from another branch that is not yet merged with master?

[Igor Djordjevic]

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---M1M2 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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Igor Djordjevic]

On Thursday, February 9, 2017 at 5:58:56 PM UTC+1, Stephen Morton wrote:
>
>  Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton <stephen@gmail.com 
> > wrote:
>>
>> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <igor.d.d...@gmail.com 
>> > wrote:
>>
>>> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>>>
>>>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.d...@gmail.com> 
>>>> wrote:
>>>>
>>>>> For example, single (resolved) merge commit (M):
>>>>>
>>>>> 1) A---B---C---D branchA
>>>>> \   \
>>>>>  V---W---*M*---E branchB
>>>>>
>>>>> ... and conflicting merge commit (M) with multiple merge resolution 
>>>>> commits (X, Y and Z):
>>>>>
>>>>> 2) A---B---C---D branchA
>>>>> \   \
>>>>>  V---W---*M*---*X*---*Y*---*Z*---E branchB
>>>>>
>>>>> Commits D and E are new commits on the two branches, representing the 
>>>>> same code state/content in both cases. Commit Z in case (2) has the same 
>>>>> code state/content as (squash) commit M in case (1).
>>>>>
>>>>>
>>>> I think that after the situation in 2), if you do a  `git checkout 
>>>> branchA ; git merge branchB`, it will try to merge X,Y,Z,E when you only 
>>>> want it to merge E. You might say "but they'll be no-ops because they're 
>>>> already in A", but this is just not necessarily true.
>>>>
>>>
>>> I think you`re wrong here, here`s what the git-merge[1] documentation 
>>> states (emphasis mine, pay attention to that part):
>>>
>>> "With the strategies that use 3-way merge (including the default, 
>>> recursive), if a change is made on both branches, but later reverted on one 
>>> of the branches, that change will be present in the merged result; some 
>>> people find this behavior confusing. It occurs because **only the heads 
>>> and the merge base are considered when performing a merge, not the 
>>> individual commits**. The merge algorithm therefore considers the 
>>> reverted change as no change at all, and substitutes the changed version 
>>> instead."
>>>
>>> So in both case (1) and (2) above, all that subsequent merge with 'git 
>>> checkout branchA; git merge branchB' considers/sees are branch head 
>>> commits D and E, and common base commit C -- only these three, and they`re 
>>> the same in both cases, thus the merge result is the same, no matter the 
>>> different individual commits in between.
>>>
>>
>> *(Oops, hit [send] to early.)*
>
> *No.*
>

Hmm... *Yes*? :D
 

> Think about what the files in the repo looks like at state M and what 
> commits X,Y,Z look like. M has lots of *committed conflict markers in it*. 
> Commit X will 100% definitely involve removing committed conflict markers 
> (and probably removing one of the "ours" or "theirs" sections). Commit X 
> might also involve code refactoring.  So `git diff M E` that you are 
> applying to A will also 100% definitely involve removing a bunch of 
> conflict markers. This is independent of considering each of the individual 
> commits, to specifically address the point above. What happens if you try 
> to apply that diff to branchA? Chaos is what happens, on the scale of 
> hundreds of files, and that's what I'm talking about.
>

All this has nothing to do with 'git checkout branchA; git merge branchB' you 
were concerned with and what we were discussing so far. For that merge to 
happen, only D and E (branch heads) and C (common base) are relevant, that 
is diffs C..D and C..E, and these are _the same_ in both cases you 
mentioned. Commits M, X, Y and Z are all irrelevant here (and their diffs 
as well).

If you`re complaining that once you resolve all the merge conflicts in Z 
and try to merge branchB back to branchA all the hell breaks loose (again), 
that is very true -- but that is something you`re imposing with your 
current flow, having branchA and branchB so much different (like totally 
different projects), and both long living and alive, and still merging 
between them back and forth.

And that is something you still have with your preferred case (1) as well 
(without commits X, Y and Z), as as soon you try to merge E back to D it`s 
still the same, _every_ resolution/refactoring contained in merge commit M 
will get inside your branchA (through that commit E).

I had tried to avoid just this kind of wild goose chase w

[git-users] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Igor Djordjevic]

>
> ... and (2) either way, you end up with with branchA state being the same 
> (whichever of the two paths you take).
>

 p.s. Just to clarify "branchA state being the same" - once you eventually 
do that 'git merge branchB' in the future, that is, no matter if you`re 
merging from z directly, or from redone/resolved merge commit (being the 
same as z).

-- 
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] Re: Git branching and merge strategy for merge with lots of conflicts requiring multiple people

[Igor Djordjevic]

On Wednesday, January 25, 2017 at 11:17:11 PM UTC+1, Stephen Morton wrote:
>
> I'm looking for a git branching and merge strategy for merge with lots of 
> conflicts requiring multiple people. I can make it work, and I understand 
> git, but it all seems kind of awkward and it feels like there must be a 
> better way.
>
> I've got a big git merge to do. There are lots of conflicts and it 
> requires many people to resolve them all.
>
> The only way to handle this in git, AFAIK, is to start the merge and then 
> just commit all files with conflicts in them and then let different people 
> work on the different conflicts, committing them as they go. That is great 
> for resolving the conflicts. In the diagram below, branchA is merged into 
> branchB with merge commit M. The code in the repo at M is full of 
> conflicts. Many of the conflicts in the merge are actually resolved in 
> commits x, y, z.
>
> o---o---o---o branchA
>  \   \
>   \-o---o-M---x---y---z branchB
>
>
> But I worry that the above strategy is not good for git's merge tracking 
> and future merges. Because if we do a 'git checkout branchA; git merge 
> branchB`, git will erroneously try to merge x,y,z into branchA.
>
> I *could *create branchB2 where I re-do the original merge but then just `git 
> checkout z -- . ` and commit that as the merge commit. That would work 
> well for the git merge tracking. Then I would keep branchB just as 
> historical reference for "who fixed what conflict and why" during the merge.
>
>
> The above would all work, but it seems so un-git-like. It feels like there 
> must be a much better and established practice, yet I have not found 
> anything online. Is there a better way to do this?
>
> Thanks,
> Steve
>
> p.s. I'm aware of answers like "Your workflow is broken, with git you 
> merge often and therefore never have lots of conflicts." It's just too long 
> a discussion to argue that point, so let's just avoid it, ok.
>

I`m sorry, but what I`m missing here is what you are actually trying to 
accomplish...?

I mean, you provided the graph, and you say you`re worried that if you do 'git 
checkout branchA; git merge branchB', commits x, y and z would 
"erroneously" end up in branchA, which should mean it is something you 
don`t want to happen.

BUT, then you say that you _could_ redo the merge, do 'git checkout z -- .' and 
commit that as resolved merge commit, and you would be happy with it (once 
you later merge branchB into branchA to introduce some new changes from 
branchB into branch A), keeping old (and unmerged) branchB for reference 
(commits x, y, z).

Now, I`m still pretty new to git, so please excuse me if I`m missing 
something, but how would that be different than just simply doing 'git 
checkout branchA; git merge branchB' in the first place (with the graph 
you`ve shown) - which you said you want to avoid...?

It seems the only difference would be keeping all x, y, z commits still in 
there (branchA history), which you first said you don`t want, but then 
later showed that you do actually seem to care about (in terms of changes 
they introduce), as you would be fine with committing them all at once as 
part of the (resolved) merge commit...?

I`m sorry if I`m failing to grasp something obvious here, I`m just a bit 
confused - you don`t want the commits (initial 'git merge branchB' concern), 
but you do want the changes (redo merge, checkout z, resolve commit)... but 
you also would like to have the history. But, (1) commits x, y and z _are_ 
history, and (2) either way, you end up with with branchA state being the 
same (whichever of the two paths you take).

So, what is that you would actually like to do (and I`m missing to get 
here)...? :)

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-apply: do not show *inherited* whitespace errors?

[Igor Djordjevic]

Hi Philip,

No worries, and thanks for your response once again. Unfortunately, that 
very latter part is the essence of my (original) question, just providing a 
step-by-step example of what I`m talking about :)

I have no issue "per se", thus question about my project size/position has 
no much sense. I`m discussing the current Git logic, and the example 
provided at the latter part of the previous message is all that`s needed to 
replicate my concern.

But to satisfy your curiosity (and just in case it *does* matter :), 
provided example works the same with both "git version 2.10.2.windows.1" 
and "git version 2.11.0.windows.1".

I totally understand the problematics you`re describing, and having Git 
trying to assist and ease the pain is great, but it seems to be lacking a 
fundamental option to *not* warn/fail on line ending *not* being changed, 
and even worse, to warn/fail when line ending *does* change -- without a 
need to *assume* or *know* which line ending should be considered 
"correct", but just to warn/fail on *change*, no further knowledge needed.

In the end, I may repost the cleaned-up version of this topic to the main 
Git mailing list, providing this one as a reference, as it may be more 
concerned of actual Git internals and its overall logic/approach, where I 
don`t really have an "issue" I would be needing help with, thus this 
git-users group might have not been appropriate for this discussion after 
all.

Thanks for your time once again, and please feel free to tune in here (or 
there) again as you see fit, and as the time allows. Happy holidays!

BugA

On Saturday, December 24, 2016 at 10:17:49 AM UTC+1, Philip Oakley wrote:
>
> Hi Igor,
>  
> Sorry for the misunderstandings. 
>  
> I think we are agreeing that the repository content, byte for byte, is the 
> versioned artefact.
>  
> Can I ask what size of project you have / are participating in / your 
> position in any hierarchy? It helps clarify how far the issues reach.
>  
> I think you are saying that _you_ are happy that in the repo you can have 
> different files with different line endings and possibly even different 
> line endings in the same file. Each originator provides the file 'as-is', 
> in their own eol style.
>  
> That mixed eol method can work when the tools are fully eol agnostic, or 
> at least there are limited users reading each file who use the same eol 
> style.  However that can lead to issues as more people want to view more of 
> the files in multiple OS's and use tools that are not 100% eol agnostic and 
> eol preserving.
>  
> Git is quite happy with mixed eols because internally it does do the 
> byte-for-byte snapshot versioning (note that it does *not* do change set 
> versioning!, diffs are done after the fact).
>  
> Because most users don't have fully eol agnostic / eol preserving tools, 
> Git tries to provide helpers for that case, and depending on who provided 
> the Git client version, you get certain defaults preset (or not). I suspect 
> to have a Git version that has a eol helper default you were not expecting. 
> Plus there are 'old' and 'new' versions of the helpers!
>  
> Most teams end up deciding that versioning mixed eol types are a big 
> problem (of the type you are seeing), and hence decide on a project wide 
> requirement, which, given Git's Linux roots, tends to be LF eol. It then 
> becomes relatively easy to expand/contract using the helpers (internal to 
> git) in a smudge/clean filter style for the different OS's.
>  
> What version of Git are you using: GfW, Github, Git source, ... and 
> --version?
>  
> I may have been _wrong_ about the patch vs email standards issue - I use 
> the tools such as format-patch and send-email so that I don't get hit by 
> these eol problems! (outlook and gmail are terrible for that)
>  
> If you at least comment on your project and your Git client it may help.
>  
> I haven't covered the latter part of your email (time is pressing)
> --
> Philip
> Happy Christmas / festive greetings to all.
>
> - Original Message - 
> *From:* Igor Djordjevic  
> *To:* Git for human beings  
> *Cc:* philip...@iee.org  
> *Sent:* Friday, December 23, 2016 9:36 PM
> *Subject:* Re: [git-users] git-apply: do not show *inherited* whitespace 
> errors?
>
> Hi Philip, 
>
> Thanks for the extensive answer. I`ll address my concerns inline, please 
> excuse me if my lack of *nix background gets too obvious, I might be 
> missing some well known facts.
>
> In line with almost all "version control" systems, Git takes the view that 
>> what is in the reposititory 'is' the versioned artefact, rather than some 
>> small (allowable?) variant of it. 
>>
>
> I`m not following you 

Re: [git-users] git-apply: do not show *inherited* whitespace errors?

[Igor Djordjevic]

 CRLF line endings:

diff --git a/sample.txt b/sample.txt
index ff9a745..2dfb04d 100644
--- a/sample.txt
+++ b/sample.txt
@@ -1,3 +1,3 @@
 line
-line
+lin2
 line


Now, if we checkout previous file version and then apply that same patch, 
git-apply produces the warning which made me open this topic:

$ git checkout HEAD -- sample.txt
$ git apply sample.patch
sample.patch:8: trailing whitespace.
lin2
warning: 1 line adds whitespace errors.


What I don`t understand is why Git complains here, when the line ending 
didn`t even change between old/new...? I mean, I totally understand it from 
*nix point of view, but it seems counter-intuitive in regards to "stupid 
content tracking", which Git is supposed to do, while it actually tries to 
be smart here (smarter then needed, at least).

(*2*) Then, we have an even worse situation - assume the same starting 
file, but edited on *nix, changing the second line *and* its line ending as 
well:

line
lin2
line


Notice that besides "line" to "lin2" change, we now miss  on the second 
line, too. If we do git-diff now, we get this:

$ git diff sample.txt
diff --git a/sample.txt b/sample.txt
index ff9a745..0727536 100644
--- a/sample.txt
+++ b/sample.txt
@@ -1,3 +1,3 @@
 line
-line
+lin2
 line


Note how Git doesn`t complain about new line "lin2" line ending anymore (no 
"^M" marker) - even though it`s actually different than it was!

If we use --ws-error-highlight again, we can clearly see the end of line 
difference, too:

$ git diff --ws-error-highlight=old,new sample.txt
diff --git a/sample.txt b/sample.txt
index ff9a745..0727536 100644
--- a/sample.txt
+++ b/sample.txt
@@ -1,3 +1,3 @@
 line
-line^M
+lin2
 line


Git seems to stay true to its own "stupid content tracking" philosophy 
here, but one may in fact expect it to warn about actual whitespace change 
in this case, instead of the previous one, where whitespace didn`t even 
change... :/

If we output this diff to a patch file now:

$ git diff sample.txt > sample2.patch


... we can clearly see the whitespace (line ending) change:

diff --git a/sample.txt b/sample.txt
index ff9a745..0727536 100644
--- a/sample.txt
+++ b/sample.txt
@@ -1,3 +1,3 @@
 line
-line
+lin2
 line


Yet, git-apply`ing the patch above happily consumes it without any warnings:

$ git checkout HEAD -- sample.txt
$ git apply sample2.patch


... effectively (and silently) breaking our previous line endings :/


So, while (*1*) is "just" annoying (being warned about line ending 
"whitespace error" that isn`t even changed), case (*2*) seems plain wrong, 
breaking previous line ending without even a hint...

Thus, it seems we could all benefit from additional git-apply --whitespace 
option which would in fact warn on line-ending changes *only*, being it 
from CRLF to LF or vice versa, no discrimination and favoring one over the 
other :)

 If you want, have a look at the main git list [1,2] for "CRLF" to find the 
> various discussions. Torsten has continued to work the issue.
>

Thank you for this, I`ll need to investigate it in more depth for sure, 
taking some time.

Yet, what I already remarked, it seems this is the opposite of what I would 
like - have Git not bother with "assumed" or preset line ending 
"normalization", leaving that to me, but just warning me when actual line 
ending change happens so I can investigate if it`s correct or not.

That would stay true to tracking content (changes) only, and not falling 
into trap of validating its "correctness" - unless otherwise requested, of 
course, which can always be convenient, but I don`t think it should be 
imposed, especially if concept of "correctness" is assumed (like LF vs 
CRLF), and not explicitly set by user.
 

>  As a general point, it is worth separating out the different whitespace 
> errors, as the eol is just one particular issue. 
>
The space/tab/etc at end of line is another, and then tab vs space 
> indentation (for those still using teletypes[3], it's 8 spaces per 1" tab!).
>

Indeed, I`m concerned with line endings in particular here.

Thanks for your time again!

BugA
 

> --
> Philip
>  
>  
> [1] http://public-inbox.org/git 
> [2] http://public-inbox.org/git/20161130170232.19685-1-tbo...@web.de/  
> Torsten Bögershausen Wed, 30 Nov 2016, "-Xrenormalize"
> [3] https://en.wikipedia.org/wiki/Teletype_Model_33 
> https://en.wikipedia.org/wiki/Teleprinter
>  
>
> - Original Message - 
> *From:* Igor Djordjevic  
> *To:* Git for human beings  
> *Sent:* Friday, December 23, 2016 12:21 AM
> *Subject:* [git-users] git-apply: do not show *inherited* whitespace 
> errors?
>
> Hi to all, 
>
> I`m using Git for Windows mainly for now, where the issue is probably more 
> (or only) pronounced, yet I kind of feel this might be of interest acros

[git-users] git-apply: do not show *inherited* whitespace errors?

[Igor Djordjevic]

Hi to all,

I`m using Git for Windows mainly for now, where the issue is probably more 
(or only) pronounced, yet I kind of feel this might be of interest across 
platforms (for Git in general), as it makes cross-platform collaboration 
harder than it needs to be (or so it seems to me). I`m posting here and not 
on the main Git mailing list as this topic might be very well elaborated 
till now, so not to produce unnecessary noise there.

When creating a patch, Git exports line endings as they are in the file 
(usually CR+LF on Windows), yet when you apply the patch, it warns you of 
"whitespace errors" (caused by CR part) - even though no whitespace 
actually changed (both old and new hunk have the same CR+LF line endings).

Now, I may understand that in Unix world there was a need to consider 
anything other than LF line ending a "whitespace error" which should be 
reported accordingly, but with Git being widely used across platforms 
nowadays it seems it should know a bit better now, especially when line 
endings *didn`t change in the first place*.

But even worse, if I change the patch file line endings manually to LF and 
git-apply the patch like that - no warning is given, even though line 
endings are in fact different now!

I`m aware of --ws-error-highlight setting for git-diff, allowing to 
show/compare line endings between old/new lines, but manual line comparison 
seems rather impractical in case of applying multiple patches - and yet 
real whitespace errors (actually introduced with the patch we`re applying) 
are lost in the noise (or worse, not even reported, as in CR+LF to LF 
conversion).

Current git-apply --whitespace options seem to allow for a variety of 
settings, but none to warn about *new* whitespace errors *only*, or even 
more important - about line ending changes in general (as converting from 
CRLF to LF might be considered a whitespace error situation, even though 
general Git thinks differently at the moment, probably assuming you 
actually corrected an existing whitespace error... :P).

So, what are the thoughts on this? Would having an additional --whitespace 
option (like "preserve", "warn-new", "warn-changed", or something) to warn 
about *new* whitespace errors *only* make sense in general? Seems so to me, 
but yet as I`m still new around, I might be missing a bigger picture...

p.s. Please let me know if you think this should be reposted to main Git 
mailing list (or to Git for Windows one, even).

Thanks, 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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.