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
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
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
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
[ +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
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
>
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
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
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
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
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
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
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
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
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
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
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
>
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} *
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
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
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
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,
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
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
>
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
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
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'.
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.
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
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
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...@
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
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
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
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
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"
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
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
101 - 138 of 138 matches
Mail list logo