Re: [git-users] Maintaining a history of a patchset?

2016-10-23 Thread Michael 

On 2016-10-23, at 4:34 PM, Philip Oakley  wrote:

> 
> - Original Message - From: "Michael" 
> Lets say you have a system where you have an unmodified upstream source, and 
> a set of patches to get that upstream source to run on your system.
> 
> As I understand it, there are two ways to deal with this in Git:
> 
> 1. One branch is the upstream's release. This may be a full clone of the 
> upstream git repository. A second branch is the local port.
> 
> In this model, after updating the upstream, you then checkout local, and 
> merge upstream into it. Resolve conflicts from changes in the upstream, test 
> the result, commit new patches to local, and then have a "working" system. 
> Your "changeset" is the difference from the upstream to the latest in local. 
> You have a full history of everything your changeset has ever done, but your 
> total history is a bit messy.
> 
> 2. You have a continually rebased set of patches. At any time, there is a 
> straight line of changes from the last upstream release to the current local 
> port.
> 
> In this model, there is no historical record/changeset to your changeset; 
> each release of your local port changes winds up looking independent of all 
> prior changes. However, your histories for each version's localization is 
> easy to read.
> 
> Am I understanding these tradeoffs correctly? Is there a better way to keep 
> track of how your changes for porting a program to a new system have changed 
> over time?
> 
> ---
> 
> There is another way. The Git for Windows project uses a 'merging rebase / 
> rebasing merge' (one is the older method). This keeps a second parent link to 
> the older series. Have a look at dscho's work on automating all that.

Ok, can you show me where that is? Google searches either return nothing or too 
many things (I'm clearly not using the right search terms)

> You can also simply tag each release, and that will retain the old series 
> without using a branch name.
> 
> Philip

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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] Maintaining a history of a patchset?

2016-10-23 Thread Philip Oakley 


- Original Message - 
From: "Michael" 
Lets say you have a system where you have an unmodified upstream source, and 
a set of patches to get that upstream source to run on your system.


As I understand it, there are two ways to deal with this in Git:

1. One branch is the upstream's release. This may be a full clone of the 
upstream git repository. A second branch is the local port.


In this model, after updating the upstream, you then checkout local, and 
merge upstream into it. Resolve conflicts from changes in the upstream, test 
the result, commit new patches to local, and then have a "working" system. 
Your "changeset" is the difference from the upstream to the latest in local. 
You have a full history of everything your changeset has ever done, but your 
total history is a bit messy.


2. You have a continually rebased set of patches. At any time, there is a 
straight line of changes from the last upstream release to the current local 
port.


In this model, there is no historical record/changeset to your changeset; 
each release of your local port changes winds up looking independent of all 
prior changes. However, your histories for each version's localization is 
easy to read.


Am I understanding these tradeoffs correctly? Is there a better way to keep 
track of how your changes for porting a program to a new system have changed 
over time?


---

There is another way. The Git for Windows project uses a 'merging rebase / 
rebasing merge' (one is the older method). This keeps a second parent link 
to the older series. Have a look at dscho's work on automating all that.


You can also simply tag each release, and that will retain the old series 
without using a branch name.


Philip


--
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] what is the best way to handle binary files through git?

2016-10-23 Thread Philip Oakley 
Manish,

The main question you should be asking is what sort of binary files do you 
have, and why you think you need to version control them (there is a rant by 
Linus on the issue, if you look;-). 

By being clear about your binary files you will have a better idea about how to 
use Git, or one of it's adjuncts (Git-LFS, and others) for handling them.

How large are the binary files, by type?

What types of binary file?

The point being, Git is designed (optimised) for source code text files, but 
that doesn't mean it won't handle binary files just fine. Its just that they 
don't compress as well as text files which have small diffs, etc.

Philip
  - Original Message - 
  From: manish peringeth 
  To: Git for human beings 
  Sent: Sunday, October 23, 2016 6:28 PM
  Subject: [git-users] what is the best way to handle binary files through git?


  Hello Everyone,


  what is the best way to handle binary files through git in windows?


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

[git-users] Migration from ClearCase to Git

2016-10-23 Thread manish peringeth 
Hello Everyone,

My Team is currently using ClearCase for version control and we are in the 
process of migration to Git.
The main worry is about Binary files and i heard that when it comes to 
Binary files Git is not really a good option.

I want to understand if anyone can suggest me on this?

-- 
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 generate those horizontal history graphs?

2016-10-23 Thread rhkramer 
On Sunday, October 23, 2016 07:21:42 AM rhkra...@gmail.com wrote:
> (I'm not the op, and) I'm still learning git, but yesterday I was skimming
> (for another reason) man git log, and I saw some ASCII art diagrams--at the
> time, I assumed they could be generated by git.  I haven't gone back to
> check, but I will at some point.  They might have even been in the man git
> log section dealing with something like the criss-cross merge...
> 
> I'm using git version 2.1.4 (on Debian Jessie).

Ok, I did a little more looking, and there is a --graph option available for 
git log (that also works with git log --pretty=oneline --graph).

It tries to make a graph, more of a vertical thing (rather than horizontal).

ATM, I am working my way through Ry's tutorial on git (which is helping me a 
lot, so far), but the point is that I currently have no branches (or, I'm not 
sure of the best terminology, maybe I should say I have only the MASTER 
branch?), and the graph isn't that helpful nor is it complex...

But, it might be helpful with more branches, or give you an easy means to 
translate to the horizontal type diagram that you (and I) think is helpful...

Re: [git-users] How to generate those horizontal history graphs?

2016-10-23 Thread rhkramer 
On Sunday, October 23, 2016 05:26:02 AM Philip Oakley wrote:
> The ascii-art is done using the technique / tool of keyboard, hand/eye
> coordination and mono-spaced editor ;-) [Unfortunately]
> 
> As an aside, you will notice that most of the horizontal (left to right
> history) graphs are not of real history, but are of carefully selected
> examples designed to show some point, hence the hand-eye-brain coordination
> requirement.
> 
> Even the ascii --graph can be poor relative to a hand tweaked one.  Now if
> there were a way to add the right (that 'brain' input step) emphasis to --
> graph then that would be a good improvement - e.g. a criss-cross merge (see
> 'git help merge-base').

(I'm not the op, and) I'm still learning git, but yesterday I was skimming 
(for another reason) man git log, and I saw some ASCII art diagrams--at the 
time, I assumed they could be generated by git.  I haven't gone back to check, 
but I will at some point.  They might have even been in the man git log 
section dealing with something like the criss-cross merge...

I'm using git version 2.1.4 (on Debian Jessie).

Re: [git-users] How to generate those horizontal history graphs?

2016-10-23 Thread Philip Oakley 
The ascii-art is done using the technique / tool of keyboard, hand/eye 
coordination and mono-spaced editor ;-) [Unfortunately]


As an aside, you will notice that most of the horizontal (left to right 
history) graphs are not of real history, but are of carefully selected 
examples designed to show some point, hence the hand-eye-brain coordination 
requirement.


Even the ascii --graph can be poor relative to a hand tweaked one.  Now if 
there were a way to add the right (that 'brain' input step) emphasis to --  
graph then that would be a good improvement - e.g. a criss-cross merge (see 
'git help merge-base').


Philip

- Original Message - 
From: "Michael" 

To: 
Sent: Saturday, October 22, 2016 6:02 PM
Subject: [git-users] How to generate those horizontal history graphs?


What tool/command/whatever generates those nice, horizontally laid out 
images of commit history over time?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

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