Upstream history (clone/pull) is condensed into a single commit. is not always what is wanted..

[fingon]

If upstream repository is used mostly for syncing purposes, it would be nice to actually pull whole history to downstream repos as well. Perhaps an option to clone/pull? (--no-squash or something)

[grimmySwe]

The reason for squashing the history is that you transform the subrepo into the ordinary repo. If you didn't squash you would have to somehow rebuild the entire subrepo history inside your ordinary repo and that can be very complex and time consuming. It's easy for single parent commits, but when you start to think of trees it will quickly become hard.

Closing it for now, if you can think of a design that solves this in an easy way please let us know. Start with thinking of the use case, how the commits should transfer between the different repos.

[fingon]

I am mostly interested in changing how the 'clone'/'pull' semantics work. Essentially replaying everything from last merged commit, commit by commit, and then noting down the new state in the commit + .gitsubrepo should be enough, no?

Push semantics would behave like they do now, just the pull ones would be rewritten so history would not be lost (but the data would not be pushed as it already exists upstream).

Obviously it gets interesting if you push to different branch in upstream, but I am not sure the current squashed single commit helps with that either.

[fingon]

I am not sure I see the problem, as the code already essentially does that (but just squashes the result to single commit). I haven't dared to look at the gory implementation details much though, as bash scripts are scary :)

[grimmySwe]

When git-subrepo pull things into the main repo it fetches all the subrepo commits in the subrepo scope, take the current state and then transform it into the main repo scope. So there is only one subrepo commit that is actually transformed.

If I understand correctly you want to include the entire subrepo tree of commits and then you will need to transform all commits there into main repo scope. Something close to what git subtree does?

One of the main benefits of git-subrepo listed on the front page: "Your git history is kept squeaky clean."
I guess it's possible to add a no-squash flag in the future but as it's not really in the main focus I would suggest that you get your hands dirty and read through the bash code! Note though that current master is about to get a great rehaul so check the issue/216-B branch.

[fingon]

Yes. What I would like to have is essentially git subrepo CLI (= less need to stick magic in e.g. Makefiles to do particular git subtree pull/pushes) and git subtree-like functionality in the way that it preserves log history both ways (both on pull and push). git subtree has --squash option which results in subrepo-like current behavior, IIRC.

I will take a look at the bash code in my copious spare time ;-)

To explain the motivation and involved workflow, at my current consulting gig, we have (.. much simplified ..):

• repo X, with subdir Y = subrepo Z
• repo Y, with subdir Y2 = subrepo Z

and most developers committing and dealing with only repo X. However, if I do things in Y or Z, it would be nice to have the changes visible in X in non-squashed form.

git subtree + plenty of ugly shell scripts is one option, but I would prefer something that has more reasonable cli such as the subrepo. I like (among other things) the fact it sees all subrepos in the current tree, and has --all etc for pull/push, and no need to deal with lots of git-internal magic (git subtree push, if it breaks, results in interesting adventure in split, rebase/merge/hair tearing land).

[Darthholi]

I would say - try "git subhistory" for not squashing commits, till this functionality gets its way into subrepo :)

[grimmySwe]

I see your point and it's certainly a valid use case. It is though more complex then what we have today. Especially in cases where you have local changes and pull in new stuff. fredag 20 januari 2017 skrev Markus Stenberg <notifications@github.com>:

…

Yes. What I would like to have is essentially git subrepo CLI (= less need to stick magic in e.g. Makefiles to do particular git subtree pull/pushes) and git subtree-like functionality in the way that it preserves log history both ways (both on pull and push). git subtree has --squash option which results in subrepo-like current behavior, IIRC. I will take a look at the bash code in my copious spare time ;-) To explain the motivation and involved workflow, at my current consulting gig, we have (.. much simplified ..): - repo X, with subdir Y = subrepo Z - repo Y, with subdir Y2 = subrepo Z and most developers committing and dealing with only repo X. However, if I do things in Y or Z, it would be nice to have the changes visible in X in non-squashed form. git subtree + plenty of ugly shell scripts is one option, but I would prefer something that has more reasonable cli such as the subrepo. I like (among other things) the fact it sees all subrepos in the current tree, and has --all etc for pull/push, and no need to deal with lots of git-internal magic (git subtree push, if it breaks, results in interesting adventure in split, rebase/merge/hair tearing land). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#246 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGLigvvWJjS7qGGGwh-VMSBeRY38047dks5rUJgcgaJpZM4Ln4Yy> .

[blaggacao]

I have an ex vivo use case for you: https://github.com/it-projects-llc/pos-addons/pull/509 (last line)

Root cause, mis-incentivized (by github UX) interpretation of repo as a folder structure... Violation of the uncoupling paradigm for better colaboration.

@Darthholi thank you for the git-subhistory tipp.

[bluelovers]

how about like this do

fake clone history for each file with limit history and can keep author info

https://github.com/bluelovers/ws-node-novel/tree/master/packages/local-rebuild-git#readme

[FFdhorkin]

What would be nice for my usage would be to have the commits generated by subrepo pull basically look a merge commit from an orphaned branch with no other commit history. I whipped together an example tree of what I'd like git-subrepo behavior to look like:

Showing the upstream commits in this fashion would make it much easier for people in the main repo to follow the new changes when we open a PR pulling remote changes. It would eliminate any ambiguity about what commits were being merged in - a subrepo pull would simply look like a merge commit for someone not aware of subrepos.

Picture this:

That's potentially a lot of unrelated changes being squashed into one commit. Subrepo only stores a single hash of the "most recent pulled" - short of opening the remote repo, seaching for that hash, and looking at the surrounding commit graph, it's surprisingly difficult to figure out what changes just got pulled in, short of actually reviewing the code.

If nothing else, it'd be nice to try to store a list of commits (and their messages) that have been squashed as part of the message produced by subrepo pull