Re: Bug report

[Dov Grobgeld]

The following answer that I got back in 2015 from Jeff King might be
relevant to your problem:

https://marc.info/?l=git=144178948506788=2

Regards,
Dov

On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt  wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic  o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic  o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>
>> And I'm at master branch all the time...
>>
>> We wouldn't have noticed that if it weren't one important feature...
>>
>
> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
> return?
>
> Where did you find this commit?

Re: Partnership with Git

[Dov Grobgeld]

Nikita,

As git is free software, you are free to use it in any way you see fit, as
long as you adhere to its licensing terms, and to the copyright
restrictions on using the term "git". Thus there is no need to ask
permission and there does not on the git side exist any entity interested
in "cross marketing activities". If your want to use git in your products,
you are free to do so without asking, and if you need technical advice for
how to go about integrating git in your products, you can either ask here,
on stackoverflow, (and probably lots of other places) or hire a consultant
that can help you.

Hope this helps,
Dov

On Tue, Feb 21, 2017 at 4:08 PM, Nikita Malikov  wrote:
>
> Konstantin,
>
> My goal is to establish partnership relations with Git because some of
> Devart's products support Git version control system (for example dbForge
> Studio for SQL Server https://www.devart.com/dbforge/sql/studio/).
> My team and I would be glad to come up with cross-marketing activities
> between Devart and Git. We think that some users of our development products
> would be interested to switch to Git version control system.
>
> Best regards
> Nikita Malikov
>
> --
> From: "Konstantin Khomoutov" 
> Sent: 21 February, 2017 14:22
> To: "Nikita Malikov" 
> Cc: 
> Subject: Re: Partnership with Git
>
>
>> On Tue, 21 Feb 2017 13:21:38 +0200
>> "Nikita Malikov"  wrote:
>>
>>> My name is Nikita and I'm from Devart https://www.devart.com/.
>>> I would like to contact someone from executive staff of Git. I would
>>> be very thankful for some information how to do this or if someone
>>> contacts me.
>>
>>
>> Git is a free software volunteer project and as such, it has no
>> "executive staff" in the sense enterprises put into it.
>>
>> Can you maybe state your actual goals please?
>>
>> Say, if you're looking for commercial support, we could possibly
>> suggests a couple of pointers.
>>
>>
>
>

Re: Seeing git history of file including merge changes

[Dov Grobgeld]

I asked the following question on StackOverflow a while ago, but did
not receive any answers so I'll try here.

We have git repository where a file was changed on a topic branch and
this branch was then merged back into the main branch. Due to various
reasons the merge was made wrongly and as a result the changes were
not accepted during the merge. The following image shows what
happened:

   -
  (  H  )
   -
 ^
 |
 |
   -
  (  M  )
   -^
 ^   \
 |\  -Delta
 | \
 | -
 |(  B  )
 | -
 |^
 |   /  +Delta
   -/
  (  A  )
   -


The file was changed in commit B and the changes were undone in commit M.

My problem is how to view the changes to the file between a specific
commit, e.g. B and another commit in its "downstream", e.g. H.

If you do

git log -u B..H

you won't see any changes, as the changes due to M are suppressed. You
can see potential changes by doing:

git log -u --full-history B..H

which will show you that there was a merge commit, but it still won't
show you the diff between B and M.

So is there a way of seeing all changes made to a file including those
made by a merge commit?

Thanks!

Dov
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A basic question

[Dov Grobgeld]

The way you typically work with git (and with most other version
control systems) is that you have a fast changing trunk (in git often
called the master), where development is done. Once you want to
release you create a release branch off the trunk, and in that branch
you do regression testing and stability testing, and once you are
convinced that stability has been achieved, you make your release.

In parallel, and without in any way influencing your release branch,
your programmers happily commit to the trunk.

See e.g. the following excellent description of some workflow models:

http://nvie.com/posts/a-successful-git-branching-model/

Regards,
Dov

 On Thu, Oct 11, 2012 at 7:38 PM, Jim Vahl j...@wmdb.com wrote:

 Drew,

 Thanks for responding to my email!

 Yes, I did read most of the Book, although I admit that I skimmed over some
 of the more technical parts.  There is still a key part of how git is used
 in a commercial environment which I don't understand.

 When we release a new version of our product, it is comprised of over a
 hundred files.  Some of these files have not changed for years, and some
 have been revised/fixed/updated quite recently.  But what is key is that all
 of these components have passed a review and testing process.  A very
 important piece of information is what revision of each file made it into
 the release.

 I know that git takes snapshots of the repository as changes are made and
 that it is possible to reconstruct the file set at any point in time.  But
 unless rules or conventions are established, at any time the repository can
 contain files which are in the process of being modified and thus have not
 passed the testing process.  For the purpose of planning a release, we're
 interested only in the most recently tested and approved files.

 For the sake of argument, I'll assume that a committing a change implies
 that the file has passed the testing process.  So my questions are:

 1) Does git have a built-in way to get a list of all of the most recently
 committed files only at a given point in time, thus automatically recording
 the revisions of all of the component files of a release?   This implies
 that for files which are being modified or which have been staged but not
 committed, that git would go back to find the predecessor file which had
 been committed.

  2) Does git have a way of creating and exporting a list of the most
 recently committed files only?

 3) If the answer to the above questions is No, then what is the normal way
 for a programming shop which is using git to extract/assemble the list of
 approved files for building a release?

 Thank you.

 Jim Vahl

 -Original Message-
 From: Drew Northup [mailto:drew.nort...@maine.edu]
 Sent: Wednesday, October 10, 2012 12:37 PM
 To: Jim Vahl
 Cc: git@vger.kernel.org; 'Skot Davis'
 Subject: Re: A basic question

 On Wed, 2012-10-10 at 11:03 -0700, Jim Vahl wrote:
  All,
 
  Our company is researching version control software, something which
  we have not used previously.  I have a very basic question about git
  which I have not been able to answer from reading.  As I understand
  it, a git repository can be a mixture of files which are under
 development, staged or committed.
  If we make a new build of our product we will obviously only want to
  include the committed (tested) files.
 
  The question is this: what is the usual procedure to retrieve a set of
  committed  files only from the repository to place into a distribution
  or ready to build folder.  The same question goes for tagging a
  release: how does the user get the tag to reference the committed
  files only and not the most recent files which may be under development or
 undergoing testing.
 
  Thanks,
 
  Jim Vahl

 Jim,
 Have you looked at http://git-scm.com/book yet? It sounds to me like you
 have some misconceptions about how Git works. (If so, did it leave you more
 or less confused?)

 --
 -Drew Northup
 
 As opposed to vegetable or mineral error?
 -John Pescatore, SANS NewsBites Vol. 12 Num. 59


 --
 To unsubscribe from this list: send the line unsubscribe git in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html