Re: [git-users] contaminated git log

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 00:06:19 -0800 (PST)
Daniel Doron  wrote:

> >> > see screen capture here: http://postimg.org/image/esgjyhk9j/ 
> >> > had to black out some parts because of proprietary info...but I
> >> > hope you get the gist. 
> >>
> >> This "remote" stuff seems to be reachable from two tags: Alpha3
> >> and Alpha2.  What happens if you remove them?  (Be sure to think
> >> this operation through before carrying on with it.) 
> >>
> > tried deleting them...changes nothing (except for the tags being
> > gone)
> Actually it did help! I forgot to delete one TAG
> Can you explain the rational behind this?

Some theory first.

Git has "refs" -- short for "references".
There are two kinds of references: branches (actually, "heads" in Git
parlance) and tags.  Hence, references are named "thingies" which point
to commits and are for humans to easily track those commits.

Now there's the concept of commit reachability.
As you know, a commit typically has at least one parent (merge commits
have two or more).  Thus child commits reference their parent commits.
Another way to reference a commit is to have a ref (a tag or a branch)
point to it.  All commits in a Git repository form a graph; actually,
any number of graphs.  Each commit in a graph is either a "leaf" commit
or is referenced by one or more child commits.

Now back to your issue.
You explicitly asked Git to show you all the refs via the "--all"
command-line option to `git log`.  This forced the `git log` to output
the lines of history hanging off all the refs your repository had, so it
dutifully rendered everything, including those subgraphs hanging off
those "Alpha3" and "Alpha2" tags.

One problem may be in suboptimal rendering which made you think the
history "falls through" the initial commit on your "master" to the
commit tagged "Alpha3".  I've just recreated that same situation in a
toy repo:

  % git log --graph --decorate --oneline --abbrev=commit --all
  * 2bb8 (tag: Alpha3) Alt: Third
  * 6fac Alt: Second
  * ddf6 Alt: First
  * 8fda (HEAD, master) Third
  * 4230 Second
  * 8764 First
  % git cat-file commit ddf6|grep -F parent

In my case, the subgraph hanging off "Alpha3" got rendered above the one
hanging off "master" but otherwise the problem exhibits yourself
rather clearly: it may be hard to understand that ddf6 does not have
8fda as its parent.

You might want to bring this issue with the Git developers -- see [1]
on how to post to the main Git list.  If you do this, be sure to
include a link to this discussion in your mail, which is [2], but make
sure you write an actual message with as narrow formulation of your
problem as possible -- don't just drop a link to this discussion on
them: no one will bother to follow it.

1. https://gist.github.com/tfnico/4441562
2. https://groups.google.com/d/topic/git-users/Q4LJVeO8haA/discussion

-- 
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] contaminated git log

[Daniel Doron]

Thanks Konstantin, that is very thorough information. 
I will find the time and formulate a request to Git developers. 

Daniel. 

On Tuesday, November 17, 2015 at 3:59:36 PM UTC+2, Konstantin Khomoutov 
wrote:
>
> On Tue, 17 Nov 2015 00:06:19 -0800 (PST) 
> Daniel Doron  wrote: 
>
> > >> > see screen capture here: http://postimg.org/image/esgjyhk9j/ 
> > >> > had to black out some parts because of proprietary info...but I 
> > >> > hope you get the gist. 
> > >> 
> > >> This "remote" stuff seems to be reachable from two tags: Alpha3 
> > >> and Alpha2.  What happens if you remove them?  (Be sure to think 
> > >> this operation through before carrying on with it.) 
> > >> 
> > > tried deleting them...changes nothing (except for the tags being 
> > > gone) 
> > Actually it did help! I forgot to delete one TAG 
> > Can you explain the rational behind this? 
>
> Some theory first. 
>
> Git has "refs" -- short for "references". 
> There are two kinds of references: branches (actually, "heads" in Git 
> parlance) and tags.  Hence, references are named "thingies" which point 
> to commits and are for humans to easily track those commits. 
>
> Now there's the concept of commit reachability. 
> As you know, a commit typically has at least one parent (merge commits 
> have two or more).  Thus child commits reference their parent commits. 
> Another way to reference a commit is to have a ref (a tag or a branch) 
> point to it.  All commits in a Git repository form a graph; actually, 
> any number of graphs.  Each commit in a graph is either a "leaf" commit 
> or is referenced by one or more child commits. 
>
> Now back to your issue. 
> You explicitly asked Git to show you all the refs via the "--all" 
> command-line option to `git log`.  This forced the `git log` to output 
> the lines of history hanging off all the refs your repository had, so it 
> dutifully rendered everything, including those subgraphs hanging off 
> those "Alpha3" and "Alpha2" tags. 
>
> One problem may be in suboptimal rendering which made you think the 
> history "falls through" the initial commit on your "master" to the 
> commit tagged "Alpha3".  I've just recreated that same situation in a 
> toy repo: 
>
>   % git log --graph --decorate --oneline --abbrev=commit --all 
>   * 2bb8 (tag: Alpha3) Alt: Third 
>   * 6fac Alt: Second 
>   * ddf6 Alt: First 
>   * 8fda (HEAD, master) Third 
>   * 4230 Second 
>   * 8764 First 
>   % git cat-file commit ddf6|grep -F parent 
>
> In my case, the subgraph hanging off "Alpha3" got rendered above the one 
> hanging off "master" but otherwise the problem exhibits yourself 
> rather clearly: it may be hard to understand that ddf6 does not have 
> 8fda as its parent. 
>
> You might want to bring this issue with the Git developers -- see [1] 
> on how to post to the main Git list.  If you do this, be sure to 
> include a link to this discussion in your mail, which is [2], but make 
> sure you write an actual message with as narrow formulation of your 
> problem as possible -- don't just drop a link to this discussion on 
> them: no one will bother to follow it. 
>
> 1. https://gist.github.com/tfnico/4441562 
> 2. https://groups.google.com/d/topic/git-users/Q4LJVeO8haA/discussion 
>

-- 
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] How to handle a longrunning branch

[mike]

Hi,

I have had a branch, feature_xyz, for a long time ( yes I know I should not 
but it was not my call). Problem is I have not updated it with changes from 
master. So I started to do a regular rebase ( i want to keep history):

git fetch origin master
git rebase origin/master

After a while with conflicting patches (over 30...) I guess that there must 
be an easier way to do this,

So anyone out there with an better idea I am open to new ideas. What do you 
suggest?

br,

//mikael

-- 
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] How to handle a longrunning branch

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 10:02:03 -0800 (PST)
mike  wrote:

> I have had a branch, feature_xyz, for a long time ( yes I know I
> should not but it was not my call). Problem is I have not updated it
> with changes from master. So I started to do a regular rebase ( i
> want to keep history):
> 
> git fetch origin master
> git rebase origin/master
> 
> After a while with conflicting patches (over 30...) I guess that
> there must be an easier way to do this,
> 
> So anyone out there with an better idea I am open to new ideas. What
> do you suggest?

What prevents you from just merging master into it?

Rebasing is only actually needed if you want to keep your work "on top"
of the branch it was based on.  The primary use case for keeping your
patch series on top of an "upstream" branch is the need to mail them
as a series of patches to upstream or have a clean run of history for
the upstream to have an easy-to-digest merge from your branch.

If that is not needed and you just want to have your feature branch
synchronized with the branch of its origin, just merge.  And re-merge
later, when needed -- it's perfectly okay to do.

On the other hand, try analyzing what that feature branch is really for.
I mean, if merging becomes a pain, it might be a signal that the feature
branch have diverged too much from the branch of its origin and may be
an effort should be taken to bring it more in shape with the "master"
code base.  This should make both rebasing and merging easier.

Yet another approach it considering the `git rerere` tool which
basically tries to remember how you have solved conflicts during a merge
and then allows to use this "canned solution" when again in the same
situation.  I honestly did not try it but may be it will make your
rebases easier.

-- 
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] contaminated git log

[Magnus Therning]

On Mon, Nov 16, 2015 at 05:52:22AM -0800, Daniel Doron wrote:
> see screen capture here: http://postimg.org/image/esgjyhk9j/
> had to black out some parts because of proprietary info...but I hope you 
> get the gist. 

It looks to me like you've based your work on the remote repo, i.e. your
changes are descendants of the commits in the remote repo.  If that
wasn't the case, I believe your `git lola` command should show different
branches otherwise, and it doesn't.

Removing a remote will *not* remove the commits made there if you have a
local branch (e.g. `master`) that's based on those commits.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

LeBlanc's law: Later equals never.

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


signature.asc
Description: PGP signature

Re: [git-users] contaminated git log

[Gergely Polonkai]

Hello,

short answer: every commit that has a reference (tag, local or remote
branch, etc.) is visible and forever (ie. won’t get garbage collected). As
soon as you remove all references, the commits go invisible and the garbage
collector will remove them after the set number of days (30 by default, as
I recall).

Best,
Gergely

2015-11-17 9:06 GMT+01:00 Daniel Doron :

> Actually it did help! I forgot to delete one TAG
> Can you explain the rational behind this?
>
> Daniel.
>
>
> On Monday, November 16, 2015 at 6:28:37 PM UTC+2, Daniel Doron wrote:
>>
>> tried deleting them...changes nothing (except for the tags being gone)
>>
>> On Monday, November 16, 2015 at 4:13:14 PM UTC+2, Konstantin Khomoutov
>> wrote:
>>>
>>> On Mon, 16 Nov 2015 05:52:22 -0800 (PST)
>>> Daniel Doron  wrote:
>>>
>>> > see screen capture here: http://postimg.org/image/esgjyhk9j/
>>> > had to black out some parts because of proprietary info...but I hope
>>> > you get the gist.
>>>
>>> This "remote" stuff seems to be reachable from two tags: Alpha3 and
>>> Alpha2.  What happens if you remove them?  (Be sure to think this
>>> operation through before carrying on with it.)
>>>
>> --
> 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.
>

-- 
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] contaminated git log

[Daniel Doron]

Actually it did help! I forgot to delete one TAG
Can you explain the rational behind this?

Daniel. 

On Monday, November 16, 2015 at 6:28:37 PM UTC+2, Daniel Doron wrote:
>
> tried deleting them...changes nothing (except for the tags being gone)
>
> On Monday, November 16, 2015 at 4:13:14 PM UTC+2, Konstantin Khomoutov 
> wrote:
>>
>> On Mon, 16 Nov 2015 05:52:22 -0800 (PST) 
>> Daniel Doron  wrote: 
>>
>> > see screen capture here: http://postimg.org/image/esgjyhk9j/ 
>> > had to black out some parts because of proprietary info...but I hope 
>> > you get the gist. 
>>
>> This "remote" stuff seems to be reachable from two tags: Alpha3 and 
>> Alpha2.  What happens if you remove them?  (Be sure to think this 
>> operation through before carrying on with it.) 
>>
>

-- 
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] CApath: none ????

[mvs]

Thanks.  For what I understand I found on

http://blogs.msdn.com/b/phkelley/archive/2014/01/20/adding-a-corporate-or-self-signed-certificate-authority-to-git-exe-s-store.aspx

a note:

*(Note: *In the Git for Windows 2.x series, the path has changed to C:\Program 
Files (x86)\Git\mingw32\ssl\certs\ca-bundle.crt.)

Thus, what happens (or seems to happen) is that git is looking for 
certificates in the wrong location. Once you manage to tell it where the 
new location for ca-bundle is things work again. I was surprised that the 
upgrade process form 1.9.* wouldn't take care automatically of this.

Maybe this is only a problem of git for windows, and maybe not so many 
people upgraded but I could not find many complaints about this on the net.

Thanks
Maurizio

>
>

-- 
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] How to handle a longrunning branch

[mike]

Den tisdag 17 november 2015 kl. 19:40:15 UTC+1 skrev Konstantin Khomoutov:
>
> On Tue, 17 Nov 2015 10:02:03 -0800 (PST) 
> mike  wrote: 
>
> > I have had a branch, feature_xyz, for a long time ( yes I know I 
> > should not but it was not my call). Problem is I have not updated it 
> > with changes from master. So I started to do a regular rebase ( i 
> > want to keep history): 
> > 
> > git fetch origin master 
> > git rebase origin/master 
> > 
> > After a while with conflicting patches (over 30...) I guess that 
> > there must be an easier way to do this, 
> > 
> > So anyone out there with an better idea I am open to new ideas. What 
> > do you suggest? 
>
> What prevents you from just merging master into it? 
>

Not absolutely sure but I guess it is for keeping history of changes when I 
merge back to master. 

>
> Rebasing is only actually needed if you want to keep your work "on top" 
> of the branch it was based on.


What do you mean with the expression "on top"?
 

>  The primary use case for keeping your 
> patch series on top of an "upstream" branch is the need to mail them 
> as a series of patches to upstream or have a clean run of history for 
> the upstream to have an easy-to-digest merge from your branch. 
>
> br,.
>

//mikael 

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