Re: [git-users] Clone sub-directory in the main repository

[Konstantin Khomoutov]

On Tue, 6 Oct 2015 03:39:30 -0700 (PDT)
Anand Aravind  wrote:

> I had pushed my code in the structure below:
> 
> Source:
> 
>Win32
>Win64
>Ubunutu64
>Ubuntu32
> 
> I had to clone the code form Win32 Folder only.

That's impossible due to the data model of any distributed version
control system: since all replicas of a repository must have the same
data where it's really the same, the minimal unit of sharing history
(pushing, fetching and -- by extension -- cloning) is a commit.
Since any commit is a snapshot of the whole project, it's impossible to
clone something which is just a part of it.

On the other hand, you might have fallen a victim of a popular syndrome
of telling us your solution for a particular problem and asking about a
way to implement it, rather than describing the original problem itself.

What would be your real use case for such "partial" clone?
To put it another way: what do you want to achieve?

Are you seeking for minimizing the amount of bytes to be downloaded?
If yes, do you still need the whole history of changes touching the
Win32 subtree or are fine with just the latest slice of them?
Do you need to continue developing on that snapshot and pushing your
changes back or you just want to download that stuff for using it (say,
building) so your cloning operation would be a one-off gig?

Please consider all this stuff carefully before replying.

-- 
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 can I ignore insignificant change during merge ?

[Konstantin Khomoutov]

On Mon, 5 Oct 2015 05:11:29 -0700 (PDT)
Jens Brejner  wrote:

> I need to merge a branch, +100k changes. The vast majority of changes
> are insignificant, because they only represent a screen position in
> the editor, so these changes should never have been in git - but but
> MadCap Flare already put them there.
> 
> The files in question are xml, and the difference can be exemplifed
> like this
> 
> Original (when branches were created):
> html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd; 
> MadCap:lastBlockDepth="5" MadCap:lastHeight="32"
> MadCap:lastWidth="400" Branch1:
> html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd; 
> MadCap:lastBlockDepth="5" MadCap:lastHeight="24"
> MadCap:lastWidth="500" Branch2:
> html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd; 
> MadCap:lastBlockDepth="5" MadCap:lastHeight="41"
> MadCap:lastWidth="300"
> 
> How can git help me so files where the only difference matches
> something like this regex:
> /html xmlns:.* MadCap:lastHeight="\d+" MadCap:lastWidth="\d+"/
> 
> for the files that qualify, I want git to ignore the change, and
> therefor the merge-conflict, and then just accept "my" file for the
> merged changeset.
> 
> Any suggestions on how to I can have git help me with that ?

I can think of two solutions to try:

* Try with `git rerere` which is supposed to remember how you managed
  to resolve merge conflicts and reapply this knowledge when doing
  further merges.

  So you could try merging just a single or few commits from the source
  branch to have them memorized by `git rerere` and then proceed with
  the rest of the branch.

* Create a so-called "clean filter" for your madcap flare XML files
  which would apply some XSL transformation (say, via xmlstarlet or
  whatever is more convenient for your environment) which would simply
  remove or "normalize" -- by rewriting to the original value -- those
  "editor posititon" bits.  You can even employ a poor-man's approach
  and fix up these files with `sed` or some other crude non-XML-aware
  tool -- I think that could be just okay for a one-off operation.

  With this filter in place, try merging with

  git merge -s recursive -X renormalize

  More info are in `git help attributes` and `git help merge`.

In either case, I'd try adopting the solution with clean filter
for this repository so that it will save everyone's neck later.

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