[SCRIPT/RFC 3/3] git-commit--onto-parent.sh

y commented in the first place, but as I`m new to everything here I kind of feel the plain words might unfortunately describe my intention a bit better than my code, for now at least. --- 8< --- #!/bin/sh # # Copyright (c) 2017 Igor Djordjevic i=$# while test $i != 0 do # # P

Re: Problem installing Git

Hi Johannes, On 25/11/2017 23:16, Johannes Schindelin wrote: > > > [ +Cc: Git for Windows mailing list ] > > I have no idea why it claimed that that group does not exist, the > email address looks correct to me. I suspected the culprit was me not being a member of the group, where the group

Re: Problem installing Git (followup)

Hi Phil, On 24/11/2017 00:44, Phil Martel wrote: > On 11/23/2017 4:30 PM, Igor Djordjevic wrote: >> On 23/11/2017 19:51, Phil Martel wrote: >>> I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 >>> machine. When I run this installer program no mat

Re: Delivery Status Notification (Failure)

On 23/11/2017 22:30, Mail Delivery Subsystem wrote: > Hello igor.d.djordje...@gmail.com, > > We're writing to let you know that the group you tried to contact > (git-for-windows) may not exist, or you may not have permission to post > messages to the group. A few more details on why you weren't

Re: Problem installing Git

[ +Cc: Git for Windows mailing list ] Hi Phil, On 23/11/2017 19:51, Phil Martel wrote: > I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 > machine. When I run this installer program no matter what options I > try or whether I run as administrator it ends up with an error box

Re: Add feature to stop tracking files while keeping them in the index

Hi Viet, On 20/11/2017 10:52, Viet Nguyen wrote: > Currently, a file can be either tracked or untracked. So, I propose we > add a feature to stop tracking files while keeping them in the index. > > Example scenario: > - A developer would like to add some configuration files with example >

Re: Unify annotated and non-annotated tags

On 11/11/2017 03:06, Junio C Hamano wrote: > Igor Djordjevic <igor.d.djordje...@gmail.com> writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you c

Re: Unify annotated and non-annotated tags

Hi Anatoly, On 10/11/2017 11:58, anatoly techtonik wrote: > It is hard to work with Git tags, because on low level hash > of non-annotated tag is pointing to commit, but hash for > annotated tag is pointing to tag metadata. > > On low level that means that there is no way to get commit > hash

Re: Rules for backup discussion

Hi Jason, On 28/10/2017 14:49, Jason Pyeron wrote: > I would like to efficiently backup my project directories. > > I am thinking that the backup of a git enabled project should only backup the > following sets of files: > > Files under .git/ > The results of git clean -ndx > The results of

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

On 17/10/2017 19:30, Johannes Sixt wrote: > Am 17.10.2017 um 01:01 schrieb Rafael Ascensao: >>> This is worth discussing, though not my preference. The picture to "pick >>> cherries" has become quite common, and now that we use it for the name of >>> the command, "cherry-pick", the direction of

Re: [idea] File history tracking hints

Hi Pavel, On 11/09/2017 09:11, Pavel Kretov wrote: > Hi all, > > Excuse me if the topic I'm going to raise here has been already discussed > on the mailing list, forums, or IRC, but I couldn't find anything related. > > > The problem: > > Git, being "a stupid content tracker", doesn't try to

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

Hi Jason, On 15/08/2017 16:26, Jason Karns wrote: > I have a git repo that shows a different branch in > `.git/refs/remotes/origin/HEAD` than is reported by `git remote show > origin`. > > The branch is `github-rename` in refs/remotes/origin/HEAD, but shows > `master` in output of

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

On 08/08/2017 15:14, Ævar Arnfjörð Bjarmason wrote: > On Mon, Aug 07 2017, Igor Djordjevic jotted: >> On 07/08/2017 23:25, Igor Djordjevic wrote: >>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote: >>>> On Sat, Aug 05 2017, Junio C. Hamano jotted: >>>&g

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

On 07/08/2017 23:25, Igor Djordjevic wrote: > On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote: >> On Sat, Aug 05 2017, Junio C. Hamano jotted: >>> I actually consider "branch" to *never* invoking a checkout. Even >>> when "git branch -m A B" happ

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote: > On Sat, Aug 05 2017, Junio C. Hamano jotted: >> I actually consider "branch" to *never* invoking a checkout. Even >> when "git branch -m A B" happens to be done when your checked out >> branch is A and you end up being on B. That is not a

Re: Binary files

On 20/07/2017 22:40, Junio C Hamano wrote: > Igor Djordjevic <igor.d.djordje...@gmail.com> writes: >> On 20/07/2017 09:41, Volodymyr Sendetskyi wrote: >>> It is known, that git handles badly storing binary files in its >>> repositories at all. >>> This is

Re: Binary files

Hi Volodymyr, On 20/07/2017 09:41, Volodymyr Sendetskyi wrote: > It is known, that git handles badly storing binary files in its > repositories at all. > This is especially about large files: even without any changes to > these files, their copies are snapshotted on each commit. So even >

Re: "groups of files" in Git?

Eh, yet another one, sorry: On 14/07/2017 01:32, Igor Djordjevic wrote: > > $ git checkout featureA > $ git commit > $ git checkout master > $ git reset --hard HEAD^ > $ git merge <HEAD@{1} parents> The last line should stress <HEAD@{1} *

Re: "groups of files" in Git?

Just a small update/fixup: On 14/07/2017 00:39, Igor Djordjevic wrote: > I guess it would be a kind of alias to doing: > > $ git checkout featureA > $ git add ... > $ git commit > $ git checkout master > $ git reset --hard HEAD^ > $ git

Re: "groups of files" in Git?

Hi astian, On 12/07/2017 00:27, astian wrote: > Nikolay Shustov wrote: >> With Perforce, I can have multiple changelists opened, that group the >> changed files as needed. >> >> With Git I cannot seem to finding the possibility to figure out how to >> achieve the same result. And the problem is

Re: "groups of files" in Git?

On 13/07/2017 23:20, Junio C Hamano wrote: > Nikolay Shustov writes: >> My question was about how to robustly handle "multiple pending >> commits" which in Perforce are represented by concept of pending >> changelists. > > And in Git, they are represented by concept of

Re: "groups of files" in Git?

For starters, let me say that I consider myself a mere advanced beginner Git user, and I haven`t used Perforce ever before (did some reading now), but still, for what it`s worth, here are my thoughts, please bare with me :) Do feel free to correct me if I miss something. On 11/07/2017 19:39,

Re: Feature Request: Show status of the stash in git status command

Hi Randall, On 11/06/2017 19:57, Randall S. Becker wrote: > Random thought: what if a stash id could be used in the same way as > any other ref, so diff stash[0] stash[1] would be possible - > although I can see this being problematic for a merge or rebase. Not sure if I`m misunderstanding

Re: [noob] is this normal behavior

Hi Harry, Both behaviours you report are normal, specifically: On 09/05/2017 15:02, Harry Putnam wrote: > Shouldn't files that changed but are already being tracked just show > up as modified and not need adding? > ... > Since that file is already being tracked; shouldn't `git status' show >

Re: How to keep log history when renaming and changing simultaneously

Hi Urs, On 17/04/2017 13:36, Urs Thuermann wrote: > Sometimes I need to rename and change a file in one commit. One > example would be a file foo.h that begins with > > #ifndef FOO_H > #define FOO_H > > which should be renamed bar.h and have the FOO_H changed to BAR_H. > In subversion

Re: broken text encoding in commit author name

Hi Michał, On 08/04/2017 22:30, Michał Walenciak wrote: > Hi > > since git 2.12 I'm having random problems with broken text enciding in author > name. > > As an example broken commit: > Author: Michał Walenciak 2017-04-07 21:38:23 > Committer: Michał Walenciak

Re: how-to get commit content with pre-receive hook ?

Hello Eric, On 06/04/2017 16:03, Eric Belhomme wrote: > Until now I ever had a quite "basic" Git usage, but now I'm working > on a project based on Git hooks feature.. and I'm a very beginner > with Git hooks ! > > My need consist doing a syntax check on submitted files before a 'git > push'.

Re: [git-gui] Amending doesn't preserve timestamp

Hi Juraj, On 23/03/2017 15:26, Juraj Oršulić wrote: > Hello Igor (and others), I have something else to report about the > commit amend functionality in git-gui, and I think it could be > related to my original question. It seems that git-gui messes up > international signs on amending. > > E.g.

Re: Possible bug: git pull --rebase discards local commits

Hi Junio, On 23/08/2016 21:28, Junio C Hamano wrote: > Joshua Phillips writes: > > I've found a case where git pull --rebase discards commits in my branch > > if the remote-tracking branch was rewound (and the remote tracking > > branch's reflog contains my branch's latest

Re: Reference for quote "creating branch is not the issue, merging is", in context of Subversion/Git

Hello Michael, On 26/02/2017 12:40, Michael Hüttermann wrote: > Linus Torvalds made a statement regarding merging/branching and stated > (as far as I know) that "creating branch is not the issue, merge is", in > context of Subversion/Git. > I do not find the origin source for that. Can you please

Fwd: Re: feature request: user email config per domain

Forwarding a message that ended on my end only, probably by accident. Forwarded Message Subject: Re: feature request: user email config per domain Date: Thu, 23 Feb 2017 13:32:56 +0530 From: Tushar Kapila <tgkp...@gmail.com> To: Igor Djordjevic BugA <igor.d.djordje...@

Re: feature request: user email config per domain

Hi Tushar, On 22/02/2017 14:12, Tushar Kapila wrote: > So when remote URL has github.com push as tgkp...@search.com but for > testing.abc.doman:8080 use tgkp...@test.xyz.com ? I`m not sure if this is sensible, as authorship information is baked into the commit at the time of

Re: [git-gui] Amending doesn't preserve timestamp

On 12/02/2017 22:40, Juraj wrote: > Hi Igor, > > I forgot to write the version I'm using. It's on Ubuntu 16.04, git-gui > package version 1:2.7.4-0ubuntu1 (--version: git-gui version 0.20.0), > git version 2.7.4, tcl and tk 8.6.0+9. Perhaps it got fixed in a newer > version, in that case, my bad

Re: [git-gui] Amending doesn't preserve timestamp

On 12/02/2017 21:50, Juraj wrote: > I've just noticed that amending a commit from git-gui uses the time of > amending as the new timestamp of the commit, whereas git commit > --amend preserves the original timestamp. Maybe the two should work > the same, whatever it is decided to be the standard

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

On 27/12/2016 18:27, Junio C Hamano wrote: > To see the problem with "check existing lines", it probably is > easier to extend the above example to start from a file with one > more line, like this: > > 1 > 3 > 4 > 5 > > and extend all the example patches to remove "4 " line

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

Hi Junio, and thanks for sharing your thoughts. You understood it pretty well, except the context "scope". Example does show a single line change, and a single line old/new comparison, but that is for simplicity sake of the initial example. What I was discussing about was the whole patch "hunk"

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

On 26/12/2016 00:49, Igor Djordjevic BugA wrote: > This is a follow-up of a message posted at git-users Google group[1], > as the topic may actually be better suited for this mailing list > instead. If needed, some elaboration on the context can be found there, > as well as a deta

git-apply: warn/fail on *changed* end of line (eol) *only*?

Hi to all, This is a follow-up of a message posted at git-users Google group[1], as the topic may actually be better suited for this mailing list instead. If needed, some elaboration on the context can be found there, as well as a detailed example describing the motive for the question itself (or

<    1   2