[git-users] How to Move from Dropbox to Git

[Ray Joseph]

Our team is using Dropbox and we want to change to Git.  I have seen many 
articles on how to use them together, but not how to transition.  Is it 
possible to capture the Dropbox versioning over to a new Git repo?

-- 
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] Bringing back botched history in a rebaseable state

[Philip Oakley]

Marc,

The other aspect is that 'rebase' does not always play well with merges. It 
(rebase) was designed to handle just a single feature branch, not one that 
has merges within it.


Philip

- Original Message - 
From: "Konstantin Khomoutov" 

To: 
Sent: Tuesday, August 29, 2017 9:14 AM
Subject: Re: [git-users] Bringing back botched history in a rebaseable state



On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote:

> > But when I try to git rebase fan upon master, I get the same file 
> > that
> > is even in the diff between msater and fan over and over again. I 
> > guess
> > that git rebase goes back to commit 2357bcc where fan was branched 
> > off
> > master and tries to reapply all changes one by one, most of which 
> > have
> > been rolled back since then or have already been done in master. I 
> > have
> > merged msater into fan multiple times in the hope that this would 
> > make

> > rebasing possible again, but to no avail.

[...]

> One way would be to merge with --no-commit then manually fixing up the
> results (by picking the correct contents for particular files using
> `git checkout`) and then staging the changes and comitting.

Only the issue is that I don't want to merge, I want to rebase.


Sorry, I was in a hurry and misread your actual problem statement :-(

For rebasing, one way to attack the problem is to "be explicit" about
both the range of commits to rebase and the point to rebase them onto.

You specify the range as usually -- by using the hash name of the
immediate parent of the "bottom" commit in the range, and use the "--onto"
command-line option to tell the rebase where you want to plant that
range on.

Another possibility is to identify which commit really make "fan"
different from "master", reset "fan" to point to "master" and then
cherry-pick those commits from the old state of "fan".

Since you were about to rebase "fan" anyway, there's no problem with
keeping the "fan" history untouched, I reckon.

--
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] Is it possbile to achive GIT Workflow with advanced access controll

[Philip Oakley]

I'm going to be a bit bold, but at the moment there is no regular way to 
achieve this. Git was developed for the open source community, so "Open" is at 
the core of the design. Git doesn't do access control. I've not used Gitolite 
which apparently does provide some repo level control.

There is work on-going in conjunction with the Microsoft Visual Studio team and 
the Windows big repo team to allow a networked scheme where the repo is on 
network and only those files required are downloaded (on-demand) to the user's 
machine.

There is some other work on lazy object loading as well.

Personally I'd also like a "narrow clone" capability to complement the 'shallow 
clone' such that some form of 'ignore spec' is used to limit what is in the 
pack files that are downloaded to the user to contain just those directories 
and files that are permitted (i.e. not excluded). In that case the local user 
would still be able to create commits, with updated trees and blobs, but 
without needing the content of the unchanged, un-released trees and blobs. It 
would have the same issues as "submodules" in having the possibility of having 
'gaps' in the (worktrees of the) history tree.

So unfortunately the current answer is 'no'.


The alternative is to have a set of hooks e.g. pre-commit, or pre-recieve, so 
that the user and the server can check if the rules have been followed, and 
reject commits that do not follow the rules. This does however mean that all 
the coders do see all the code, which may be a 'security' issue.

philip
  - Original Message - 
  From: kane...@gmail.com 
  To: Git for human beings 
  Sent: Tuesday, August 29, 2017 5:31 PM
  Subject: [git-users] Is it possbile to achive GIT Workflow with advanced 
access controll


  Hello.

  I am in progress of searching efficient way to use GIT work-flow with 
advanced access permissions. The work flow is this: 
http://nvie.com/posts/a-successful-git-branching-model/ but simpler alternative 
can be taken in order to understand the actual requirement which is described 
in the next paragraph.

  What seems I need is to configure each developer with file/directory 
permissions (may not include "list" permission but only read and write if no 
"read" permission means that the DEV will not see the file/directory at all). 
That way I will be able to share enough but limited part of software with a 
developer. The second important thing is that he should still be able to send 
pull requests for merge but only with the source addition and/or modification 
in the allowed directories/files.

  To aggregate the question: is there any way to use given GIT Workflow with 
the ability to share partially the repository and still use the full potential 
of GIT repository. Git modules and subtree is not efficient and seems for 
another use-cases because they will sacrifice the repository power.


  -- 
  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] Bringing back botched history in a rebaseable state

[Konstantin Khomoutov]

On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote:

> > > But when I try to git rebase fan upon master, I get the same file that
> > > is even in the diff between msater and fan over and over again. I guess
> > > that git rebase goes back to commit 2357bcc where fan was branched off
> > > master and tries to reapply all changes one by one, most of which have
> > > been rolled back since then or have already been done in master. I have
> > > merged msater into fan multiple times in the hope that this would make
> > > rebasing possible again, but to no avail.
[...]
> > One way would be to merge with --no-commit then manually fixing up the
> > results (by picking the correct contents for particular files using
> > `git checkout`) and then staging the changes and comitting.
> 
> Only the issue is that I don't want to merge, I want to rebase.

Sorry, I was in a hurry and misread your actual problem statement :-(

For rebasing, one way to attack the problem is to "be explicit" about
both the range of commits to rebase and the point to rebase them onto.

You specify the range as usually -- by using the hash name of the
immediate parent of the "bottom" commit in the range, and use the "--onto"
command-line option to tell the rebase where you want to plant that
range on.

Another possibility is to identify which commit really make "fan"
different from "master", reset "fan" to point to "master" and then
cherry-pick those commits from the old state of "fan".

Since you were about to rebase "fan" anyway, there's no problem with
keeping the "fan" history untouched, I reckon.

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