|
Or "git pull --rebase" in your branch. Definitely nicer than pushing something with a bunch of merge commits.
|
#
?
Sep 1, 2016 23:15
|
|
|
|
| # ? May 13, 2024 07:23 |
|
|
Thanks. I'll probably just use git pull --rebase, as it's simple but explicit. Since I'm helping classmates with less experience than me, I don't want to reconfigure pull's default behavior.
|
|
#
?
Sep 1, 2016 23:20
|
|
|
I'm trying to think of instances where git pull --rebase would gently caress up or be the wrong answer, and I'm coming up empty. Unless you're in a group that wants every merge commit for 100% true to life history, and nuts to that.
|
|
#
?
Sep 1, 2016 23:27
|
|
|
Ciaphas posted:I'm trying to think of instances where git pull --rebase would gently caress up or be the wrong answer, and I'm coming up empty. Unless you're in a group that wants every merge commit for 100% true to life history, and nuts to that. Speaking as someone who has git pull setup to rebase by default, I have encountered the following situation: Your upstream looks like oldest -> older -> old. Your checkout is up-to-date with upstream. Your coworker has been doing some work and hasn't pulled in a few hours. Their checkout looks like oldest -> unpublished. Your coworker asks you to pull directly from their checkout and take a look at what they're doing. What you want your repo to look like, in the best possible world: oldest -> older -> old -> unpublished (rebasing their tree to the head of your tree). What would be acceptable, if somewhat annoying: getting an error saying that you have to do some sort of manual merge, because you have very stupidly asked to do a rebasing pull from a checkout that is not your upstream. What git pull --rebase actually does: oldest -> unpublished -> older -> old (rebasing your tree to the head of their tree). In summary, git pull --rebase works perfectly as long as you remember that it always moves the commits that are in your tree to be at the end of where you're pulling from. If you're pulling "unpublished" commits which should be rebased, then you need to rebase in "the other direction" that what it does by default. That said, this is not a common situation and it's super easy to avoid.
|
|
#
?
Sep 1, 2016 23:41
|
|
|
Yeah usually if I'm not 100% sure of what the history on all ends looks like I'll just fetch and either merge, rebase, or do nothing as required (headless checkout is fine if I'm just reviewing), so I haven't run into that edge case yet.
|
|
#
?
Sep 1, 2016 23:49
|
|
|
How do y'all feel about history-rewriting on published feature branches? I feel as long as it's obviously my personal feature branch it's cool to do whatever to the history even though it's technically public, but I guess it gets iffy when someone else shows up and wants to work on the same thing.
|
|
#
?
Sep 2, 2016 00:39
|
|
|
Vanadium posted:How do y'all feel about history-rewriting on published feature branches? I feel as long as it's obviously my personal feature branch it's cool to do whatever to the history even though it's technically public, but I guess it gets iffy when someone else shows up and wants to work on the same thing. Are other people using it? if so probably don't. That said on my repos on github I require people rebase fixes for their pull request instead of adding more and more 'fix X' commits.
|
|
#
?
Sep 2, 2016 04:45
|
|
|
Thermopyle posted:What's the best/fairest/easiest/most-standard way to handle this workflow? 1. They do a merge on your master before you make any changes. It should be a no-op merge since you should have no outstanding changes on it, but if there are they need to check if the merge has any material changes, and if it does, figure out if they need to incorporate them, otherwise they'll end up doing the equivalent of an "ours" merge. Either way, you're now on equal footing. Then you can make your changes on master and they can merge them in, since the changes are orthogonal there shouldn't be conflict. 2. You make a branch of their master and pretend to be "them" in option #1. So you're still doing work on "your" master and merging it into "theirs", handling any conflicts that come along the way, while periodically pulling from their real master. For delivery, you tell them to pull from your version of "their" master and since you've already resolved the conflicts, they should be clean merges. For either approach to be worthwhile though there has to be value in maintaining your changes on an external branch. You probably already know this, but if was, for example, an open-source project where you're allowed by contract to maintain your changes in the open, then you can use those changes later on other projects while avoiding the IP issues (or general maintenance issues) around their version. If the changes you make can't be repurposed though, there may not be much value in maintaining them separately.
|
|
#
?
Sep 3, 2016 19:04
|
|
|
Snak posted:When my local copy of master gets behind the remote, it seems like that's when it's better to rebase my local to the remote, rather than merge them. Does that seem correct? If you're referring to small changes you're making on master outside of a feature branch, then yes it's usually easier to rebase those against master than to merge. Nobody really likes "one commit + one merge commit" showing up in history all the time. ExcessBLarg! fucked around with this message at 19:11 on Sep 3, 2016 |
|
#
?
Sep 3, 2016 19:07
|
|
|
Vanadium posted:How do y'all feel about history-rewriting on published feature branches? For branches that are truly private, I'll usually prefix the branch with my username so it's clear to others that I own it, and that I'll probably be regularly force-pushing to it.
|
|
#
?
Sep 3, 2016 19:10
|
|
|
This is in a class where a lot of people are using git for the first time, so people are constantly pushing new or broken files to master. People creating files in the wrong directory and people pushing without checking that it still compiles after their changes. So it's not a huge deal to clean this stuff up, but I would rather push my feature branch merge commit and then fix the mess on a seperate "cleaned up bad files" commit. Does that make sense? I'm new at this too, I'm just a little more comfortable with how git works than some of my classmates, so I'm trying to be as helpful as possible.
|
|
#
?
Sep 3, 2016 19:14
|
|
|
Snak posted:This is in a class where a lot of people are using git for the first time, so people are constantly pushing new or broken files to master. People creating files in the wrong directory and people pushing without checking that it still compiles after their changes. You shouldn't have broken commits in the tree. There's probably not much you can do dealing with students but stuff shouldn't get merged to master if it doesn't loving work. You should strive to never have commits like "fix breakage" or "address reviewer comments"
|
|
#
?
Sep 3, 2016 19:18
|
|
|
Making a separate commit for cleaning up crap to differentiate it from your features is preferable, yes. But when you're at the level where classmates can't even be bothered to check if their code compiles, much less runs, git feng shui is pretty far down on the lot of priorities
|
|
#
?
Sep 4, 2016 00:00
|
|
|
Series DD Funding posted:Making a separate commit for cleaning up crap to differentiate it from your features is preferable, yes. But when you're at the level where classmates can't even be bothered to check if their code compiles, much less runs, git feng shui is pretty far down on the lot of priorities Yeah, but I don't want to develop bad habits because they are convenient in school. I want to practice doing things the right way.
|
|
#
?
Sep 4, 2016 04:39
|
|
|
What is an easy way to deal with ancillary changes that happened to a file that I'm committing to keep the commits clean? (in git) For example, I was working on a file that had a few lines with extra spaces at the end of the line. My editor cleaned those up automatically, but I'd like to not keep those changes in the feature commit. Is there a way to commit part of a file? I'd like to be able to make the ancillary changes another separate commit ("removed extraneous whitespace"). Last time, I just put the extra spaces back in to get around it quick, but that doesn't seem like the right way to do it. I know one answer is "don't make unrelated changes at that time" but sometimes it just happens or it is a good time to make a little change or it will get lost in the todo list.
|
|
#
?
Sep 4, 2016 17:35
|
|
|
taqueso posted:What is an easy way to deal with ancillary changes that happened to a file that I'm committing to keep the commits clean? (in git) git add -p
|
|
#
?
Sep 4, 2016 17:38
|
|
|
Thank you
|
|
#
?
Sep 4, 2016 18:42
|
|
|
Snak posted:Yeah, but I don't want to develop bad habits because they are convenient in school. I want to practice doing things the right way. I wouldn't worry too much about getting git right on this. Do your work on a private branch (doesn't really need to be a feature branch), folding in their changes at convenient times, but don't worry too much about having a perfect history. I'm guessing it's not that long of project (beyond one semester) anyways. The only things you really need to be able to do is cursory review of others changes, and be able to revert to a known-working version when poo poo really breaks. If you really want to learn git well, get involved in some established projects that exhibit good commit, merge, and review policies.
|
|
#
?
Sep 4, 2016 18:51
|
|
|
Snak posted:Yeah, but I don't want to develop bad habits because they are convenient in school. I want to practice doing things the right way. Just to say, don't expect things to necessarily be better in the real world. There's a dev in my team who doesn't seem to be able to get his head around source control, how to use it well, or why it's even a good idea. He often won't commit or push anything until he's prompted, and then you get a fortnight's work in a single commit with the message 'Update'. He mostly gets away with it because we do a lot of working on our own individual projects, it only tends to come to light in situations like the current one where he's in India, and I'm called upon to fix something he's worked on, find out that the remote hasn't been updated since god knows when and all the most recent changes are in uncommitted files in his working directory that I can't even commit and push because nobody knows his git password! That's once I've worked out which of the multiple versions of each project is even the right one, because he makes multiple stupidly named backup copies of everything because he doesn't use source control. He's a loving nightmare. (and yes, I am considering a move before anyone suggests it)
|
|
#
?
Sep 5, 2016 13:10
|
|
|
Quick rebase question: I've got a fairly long running feature branch. A few commits back I merged it into my develop branch, but I continued working on it. If I were to now rebase it onto develop, would it just rebase the few commits that were made since the last time I merge it in, or everything from the point the branch was created?
|
|
#
?
Sep 7, 2016 10:26
|
|
|
Rebase ignores merge commits by default, and just FYI you can use --preserve-merges to bypass this. I think the machinery for --preserve-merges is a bit involved though, it doesn't always include all merge commits to avoid redundancy or something, I dunno.
|
|
#
?
Sep 7, 2016 12:38
|
|
|
chippy posted:Quick rebase question: I've got a fairly long running feature branch. A few commits back I merged it into my develop branch, but I continued working on it. If I were to now rebase it onto develop, would it just rebase the few commits that were made since the last time I merge it in, or everything from the point the branch was created? It will see that the older commits are already there in the branch you are rebasing on to, and not try to reapply them.
|
|
#
?
Sep 7, 2016 17:12
|
|
|
So -- philosophical git question. Imagine working in an environment that has extraordinary legal compliance or contractual obligations in regards to change management, auditing, etc. etc. Wouldn't using a RCS that allows you to effectively rewrite history (rebase) be.... an extraordinarily bad idea?
|
|
#
?
Sep 10, 2016 01:16
|
|
|
Pixelboy posted:So -- philosophical git question. Imagine working in an environment that has extraordinary legal compliance or contractual obligations in regards to change management, auditing, etc. etc. You can rewrite any version control system's history. Git is far more robust to losing old commits (even when rebasing) than things like svn. Git is far more robust against modification of the history too. tl;dr: no. apseudonym fucked around with this message at 02:05 on Sep 10, 2016 |
|
#
?
Sep 10, 2016 01:25
|
|
|
when people refer to rewriting history as useful they usually mean only the history of private commits or stories not merged to a main branch yet rewriting public history is generally avoided
|
|
#
?
Sep 10, 2016 01:47
|
|
|
Also pretty much every Git service now supports blocking force pushes (rewrites) to protected branches such as master, so you can certainly ensure that history isn't changed.
|
|
#
?
Sep 10, 2016 02:14
|
|
|
More relevantly, as apseudonym suggested, git does not actually support genuinely rewriting history at all, just moving branch pointers around, which is recorded in the reflog. Normally unreferenced commits (as arise from "rewritten" history) are garbage collected after a month or so, but you can just disable that if you have extraordinary demands.
|
|
#
?
Sep 10, 2016 02:22
|
|
|
apseudonym posted:You can rewrite any version control system's history. As an end user?
|
|
#
?
Sep 24, 2016 13:21
|
|
|
On GitHub, for general viewing, do I want to let the files upload with the crlf line endings, and then just configure my Windows computer to automatically convert from crlf to lf usingcode:That's what it sounds like from [url=https://help.github.com/articles/dealing-with-line-endings/[/url], but I want to make sure that's how it's generally done.
|
|
#
?
Sep 30, 2016 19:52
|
|
|
I asked this question about git log on stack overflow: http://stackoverflow.com/questions/39946636/git-log-inconsistency-in-file-states The problem is that the log for a file seems inconsistent; it looks like the file was deleted, but it is then edited and still exists. It looks from the log as though it went: Add --> [bunch of edits] --> Delete --> [bunch of edits] I've added a gist here to show the file I mean, the highlighted line is the delete. Is there something fundamental I'm missing about git log? The command I am running is: code:
|
|
#
?
Oct 9, 2016 19:00
|
|
|
Is it possible the next commit is a merge and they chose to take their own modified version over the deleted version?
|
|
#
?
Oct 10, 2016 13:18
|
|
|
Gounads posted:Is it possible the next commit is a merge and they chose to take their own modified version over the deleted version? It's probably this. I did this: code:code:
|
|
#
?
Oct 10, 2016 22:47
|
|
|
git log --graph makes logs involves merges much more sensible.
|
|
#
?
Oct 11, 2016 00:12
|
|
|
I need to apply the inverse of a git stash, or something. I edited a file, made change A. Then I stashed this change away. Then I went into my text editor, and made change B. At this point I thought change A was gone, but I think the editor had not reloaded from disk so that stashed change was still there. Now if I run a "git diff" i see changes A and B. Is there something I can do to unapply that stash, so that if I run "git diff" it will only show me change B? I was asking on IRC, and someone suggested I do "git show stash | git apply -R", but that results in "fatal: unrecognized input" They think "the problem is that git stash saves the stash as a merge commit", so I have no idea what to do about that and they seem out of suggestions.
|
|
#
?
Oct 16, 2016 22:41
|
|
|
peepsalot posted:I need to apply the inverse of a git stash, or something. So A didn't actually get stashed? Use git stash -p and select only the parts of A.
|
|
#
?
Oct 16, 2016 22:47
|
|
|
apseudonym posted:So A didn't actually get stashed? Use git stash -p and select only the parts of A. e: So now to isolate only "B" changes, I want to "apply" stash A, except in reverse. Does that make sense? peepsalot fucked around with this message at 22:58 on Oct 16, 2016 |
|
#
?
Oct 16, 2016 22:51
|
|
|
peepsalot posted:"A" was put in a stash, but the editor apparently did not reload the file from disk or warn me because its a piece of poo poo (atom). Git add -p?
|
|
#
?
Oct 16, 2016 23:02
|
|
|
peepsalot posted:"A" was put in a stash, but the editor apparently did not reload the file from disk or warn me because its a piece of poo poo (atom). Stash B. Make a new temporary branch from your starting point. Apply A from the stash. Commit. Apply B from stash. Commit. Check out starting point again. Cherry pick commit after applying B on the temp branch. That should isolate those changes. It's probably possible to do in a shorter way, but this seems like the most straight-forward.
|
|
#
?
Oct 16, 2016 23:15
|
|
|
I used Hughlander's suggestion and got back where I wanted to be, thanks.
|
|
#
?
Oct 16, 2016 23:22
|
|
|
|
| # ? May 13, 2024 07:23 |
|
|
I'm having problems wrapping my head around git remote right now. I've never had issues using git with github, but this is a little different. I have a collection of scripts that do various admin things, that I want to be available to my co-workers. As I add and edit new scripts I don't want to have to worry if the version on the shared folder is up to date, and I'd like to be able to do version tracking on my local copies of the scripts. My thought was to have a local repository that I do edits on, then have a remote repository that I can push changes to, that would live on the network share for people to access. They would not be using git at all, just running different scripts as needed. What would be the best way to set this up?
|
|
#
?
Oct 18, 2016 00:18
|
|
