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

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,

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

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

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

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

[git-users] Re: git commit --amend -F option help

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

[git-users] Re: worktree with orphan

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

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

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

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

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 >

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

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

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

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

[git-users] Re: How to see ALL my commits? Including from any branches I've made.

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?

[git-users] Re: How to remove a directory from the index?

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

> 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 wort

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

ell) > > 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, Ig

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

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

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

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

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

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

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

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: >

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

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

Re: [git-users] Git branch merge strategies

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

Re: [git-users] Git branch merge strategies

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

Re: [git-users] Git branch merge strategies

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

[git-users] Re: Malicious Coder

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.

[git-users] Re: Git Commit Sequence Issue

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

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

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:*

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

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

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

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

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

[git-users] Re: Uncommiting a merge?

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

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

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 repositor

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

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

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

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. >> >

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

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: >

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

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

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

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

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

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

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

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

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

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

[git-users] Re: git log

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

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

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

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

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 =

Re: [git-users] Undocumented reset behavior

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 >>

[git-users] Re: merge conflicts

> > 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

[git-users] Re: merge conflicts

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

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

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

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

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)

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

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

[git-users] Re: Help with rebase?

, 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, 201

[git-users] Re: Help with rebase?

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

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

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

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?

ined 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

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

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

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: >>

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

> > ... 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,

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

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

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

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

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

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

[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 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